Architecture for a universal serial bus-based pc flash disk

ARCHITECTURE FOR A UNIVERSAL SERIAL BUS-BASED PC FLASH DISK

<p>FIELD OF THE INVENTION The present invention relates to semiconductor memory devices, and more particularly, to erasable and programmable non-volatile memory modules connected to a host platform using a USB PC bus. </p>

<p>Erasable and programmable non-volatile memory modules, referred to herein as flash memories or flash devices, are known in the information storage art. Flash devices include electrically erasable and programmable read-only memory (EEPROM) comprised of flash-type floating-gate transistors, and are dependent on functionality and performance, along with additional functionality to enable internal circuit programmable operations to erase pages of memory. It is a non-volatile memory similar to EPROM memory. One embodiment of such a flash device implementation is disclosed in US Pat. No. 5,799,168, which has been described above but is incorporated by reference.</p><p>The flash device has the advantage of being relatively inexpensive and requiring relatively little power compared to the traditional magnetic storage disk. However, in a flash device, it is impractical to rewrite to a previously recorded area without erasing the preceding page of the area. This limitation of flash memories causes them to be incompatible with typical current operating system programs, since it is impossible to write data to a memory area in a flash device to which data has been previously written unless the area is first erased. A software management system, such as disclosed in U.S. Patent No. 5,404,485, filed March 5, 1993, previously incorporated herein by reference, is required to manage these functions of a flash memory device.</p><p>A second limitation of current flash memory devices is that such devices must be either statically attached to the host platform or dynamically detached using the Personal Computer Memory Card International Association (PCMCIA) interface. This implementation has drawbacks, including high cost and difficulty in use.</p><p>A more useful implementation is the USB standard referred to above as the USB Specification Version 1.1, which is referenced above. While lowering the cost of implementation, the USB standard provides a smaller form factor, making it easier for users to use. These standards are functionalized in industry-wide standards promoted by Compaq Computer Corporation, Microsoft, IBM, and Intel, providing extensions to PC architectures with a focus on Computer Telephony Integration (CTI), consumer and productivity applications. do.</p><p>Criteria applied to define the architecture for the USB standard include easy PC (personal computer) peripheral expansion, low cost, support for transfer rates over 12Mb per second, and full support for compressed video and real-time data, voice, and audio. . These standards also provide protocol flexibility for mixed-mode isochronous data transfer and asynchronous messaging, integration of commodity device technologies, and standard interfaces for rapid integration into any given host product. Additionally, the USB standard specifies a single model of cabling and attaching connectors, so that all electrical details, including bus termination, are independent of the end user. Through the standard, peripheral devices are self-identifying and support automatic mapping to drivers. Moreover, the standard allows all peripheral devices to be dynamically attachable and reconfigurable.</p><p>A system configured according to the USB standard is described in three individually defined areas: USB interconnect, USB device, and USB host platform. USB interconnection is the way USB devices connect and communicate with the host platform. Associated functions and components include a bus topology, which is a connection model between a USB device and a host platform.</p><p>The USB physical interconnect has a layered star topology. The hub is at the center of each star. Each wire segment is a point-to-point connection between a host platform and a hub or function, or a hub connected to another hub or function.</p><p>In the capability stack, USB tasks executed at each layer in the system include data flow models and schedules. The data flow model is how data in the system moves between data producers and data consumers via USB. The schedule determines access to the shared interconnect. This scheduling enables isochronous data transmission to be supported and eliminates arbitration overhead.</p><p>USB itself is a polled bus. The host controller on the host platform initiates all data transfers. Every bus transaction involves sending up to 3 packets. Each transaction starts when the host controller sends a USB packet indicating the direction and type of the transaction, the USB device address, and the endpoint number as planned. These packets are called "token packets". The USB device to which the packet is addressed selects itself by decoding the appropriate address field. For a given transaction, data is transferred from the host platform to the device or from the device to the host platform. The direction of data transfer is specified in token packets. Next, the source of the transaction either sends a data packet, or indicates that the source has no data to send. Typically, the destination responds with a handshake packet indicating that the transmission was successful.</p><p>The USB data transfer model between sources and destinations on the host platform and endpoints on the device is called a "pipe." There are two types of pipes: streams and messages. Stream data does not have a structure defined as USB, whereas message data has a structure defined as USB. Additionally, a pipe has endpoint characteristics such as data bandwidth association, transport service type, and directionality and buffer size. Most of the pipes appear when the USB device is configured. One message pipe, the Default Control Pipe, exists when a device is powered up to provide access to the device's placement, status, and control information.</p><p>The transaction schedule for the USB standard allows flow control over some stream pipes. At the hardware level, this prevents the buffer from under- or over-executing by using a NAK handshake that slows down the data rate. Due to the NAK handshake, the transaction is retried when bus time is available. The flow control mechanism makes it possible to configure flexible schedules to run concurrent services of heterogeneous mixtures of stream pipes. Thus, multiple stream pipes can be serviced at different intervals with packets of different sizes.</p><p>As mentioned above, the USB standard has three main types of packets, including token packets, data packets, and handshake packets. An embodiment of each type of packet is shown in the background of Figures 1-3. BACKGROUND FIG. 4 illustrates an exemplary USB abstract device.</p><p>BACKGROUND As shown in Figure 1, a token packet 10 features a PID (Packet Identification) field 12 specifying one of three packet types: IN, OUT, or SETUP. If the PID field 12 indicates an IN packet type, the data transaction is defined by the host platform in function. If the PID field 12 indicates an OUT or SETUP packet type, the data transaction is defined as a function in the host platform.</p><p>The ADDR field 14 indicates the address, while the ENDP field 16 indicates the endpoint for the token packet 10 . For OUT and SETUP transactions where the PID field 12 indicates that the token packet 10 is of the OUT packet type or the SETUP packet type, the ADDR field 14 and the ENDP field 16 are Uniquely identifies the endpoint receiving the next data packet following (10). For an IN transaction where the PID field 12 indicates that the token packet 10 is of type IN packet 10, the ADDR field 14 and the ENDP field 16 uniquely identify the endpoint from which the data packet is transmitted. . The CRC5 field 18 contains a checksum that determines that the token packet 10 was received without errors. Only the host platform can issue the token packet 10, so the token packet 10 provides control over the transmission of the next data packet.</p><p>BACKGROUND As shown in Fig. 2, the USB data packet 20 of the background also features a PID (Packet Identification) field 22 that identifies the data packet type. The data packet 20 is also characterized by a data field 24 optionally containing data, and a CRC field 26 containing a checksum as described above.</p><p>BACKGROUND FIG. 3 shows a background USB handshake packet 28 featuring only a PID (Packet Identification) field 30 . Handshake packet 28 is used to report the status of a data transaction, and may return values indicating successful reception of data, acceptance or rejection of commands, flow control, and stop conditions. Only transaction types that support flow control can return a handshake packet (28). The handshake packet 28 may always be returned to the handshake phase of the transaction, and may always be returned to the data phase of the transaction instead of the data packet 20 .</p><p>These three different types of packets are exchanged during various phases of a transaction involving the USB device. A structural block diagram of the functional blocks of a typical USB device 32 is shown in FIG. 4 for an abstract background USB device 32 . USB device 32 typically includes a USB electrical interface 34 that features a cable and connector and is a physical interface for transmitting and receiving electrical signals compatible with the USB specification as above. This signal is then sent to a logical interface 36 comprising one or more buffers, a device address decoder that decodes the address of the source device relative to the signal, and a SYNC field synchronizer that synchronizes the signal. Information and structures required for management of the USB abstract device 32 as a USB device are stored in the USB class control and enumeration engine 38 . The function and device engine 40 , also called "application", controls and manages the characteristics and specific functions of the USB abstract device 32 . In addition, the function and device engine 40 also creates and consumes most of the data via the USB bus.</p><p>However, the USB specification cannot define relationships between different entities in the USB abstract device 32 . Rather, the USB specification describes only the requirements for packets and electrical and physical connections between the USB abstract device 32 and the bus. Thus, the connections and relationships shown in the background Figure 4 are one embodiment of an implementation that implements the requirements of the USB specification. Thus, any particular device implementing the USB specification must have a clearly defined and described architecture.</p>

<solutionproblem><p>Unfortunately, no such architecture exists for a flash memory device comprising one or more flash memory modules, which allows the flash memory device to be connected to a bus defined according to the USB specification to form part of a USB system on a host platform. . For example, US Pat. No. 5,799,168 does not teach or suggest such an implementation for a flash device. As noted above, the architecture is particularly useful for many reasons, including transparency to end users, ease of use, and low cost.</p><p>Thus, in order for a flash memory device to be placed on a USB defined bus and communicate with a host platform via this bus, it has an architecture that defines and describes a flash memory device that conforms to the USB specification and is compatible with the USB system. It is useful and necessary.</p></solutionproblem><meansproblemsolution><p>The present invention is a flash memory device comprising one or more flash modules, wherein the flash memory is mapped to an address space of an ASIC or controller having an electrical interface defined as USB and a logical interface defined as USB. The controller/ASIC (hereinafter referred to as "controller") supports USB functions according to the USB standard, supporting enumeration on the USB bus as well as receiving and transmitting data to and from USB endpoints via USB pipes. Such a controller also supports the functionality and control of the flash memory device as well as the processing of data packets and commands from the host controller. The host controller uses one of several possible protocols, either standard or proprietary, to signal the USB flash controller the next command to be executed. Thus, the entire device acts as a dynamically removable non-volatile storage device to the host platform.</p><p>According to the present invention, there is provided a USB flash memory device for connecting to a bus defined as USB, the flash memory device comprising (a) at least one flash memory module for storing data, (b) on a bus defined as USB a USB connector connected, for sending packets on and receiving packets from a bus defined as USB, (c) at least one such that data is read from or written to the at least one flash memory module; and a USB controller that controls the flash memory module of the USB and controls the USB connector according to at least one packet received from a bus defined as USB. </p><p>Hereinafter, the term "computer" refers to DOS, Windows<sp>TM</sp>, OS/2<sp>TM</sp>, or a personal computer (PC) with an operating system such as Linux; Macintosh<sp>TM</sp> computer; JAVA as an operating system<sp>TM</sp>- a computer with an OS; Sun Microsystems<sp>TM </sp>and Silicon Graphics<sp>TM</sp>graphics workstations such as computers; Sun Microsystems<sp>TM</sp>of AIX<sp>TM</sp> or SOLARIS<sp>TM</sp>other computers with any version of the UNIX operating system, such as; or Windows CE for embedded systems including cellular telephones, portable computing devices and palmtop computing devices, and any other computing devices that may be connected to a network.<sp>TM</sp>Any other known and usable operating system including an operating system such as, but not limited to. After the term "Windows<sp>TM</sp>" is Windows95<sp>TM</sp>, Windows3.x<sp>TM</sp>, where x is an integer equal to "1", Windows NT<sp>TM</sp>, Windows98<sp>TM</sp>, Windows CE<sp>TM</sp>, and any upgraded versions of these operating systems of Microsoft Corporation (Seattle, Washington, USA). </p></meansproblemsolution><effectiveness><p>In order for a flash memory device to be placed on a USB-defined bus and to be able to communicate with a host platform via this bus, it can have an architecture that defines and describes a flash memory device that conforms to the USB specification and is compatible with the USB system. . The above description is by way of example only, and many other embodiments are possible without departing from the spirit and scope of the invention.</p></effectiveness>

<p>The present invention consists of a flash memory device comprising one or more flash modules in which the flash memory is mapped to an address space of an ASIC or controller having an electrical interface defined as USB and a logical interface defined as USB. The controller/ASIC (hereinafter referred to as the "controller") supports USB functions according to the USB standard, supporting enumeration on the USB bus as well as receiving and transmitting data to and from USB endpoints via USB pipes. Such a controller also supports the functionality and control of the flash memory device as well as the processing of data packets and commands from the host controller. The host controller uses one of several possible protocols, standard or proprietary, to signal the next command to be executed on the USB flash controller. Thus, the entire device acts as a dynamically removable non-volatile storage device to the host platform.</p><p>While the present invention is susceptible to various modifications and may be embodied using many alternative forms, embodiments have been shown by way of example in the drawings and will be described in detail in the following pages. Those skilled in the art will recognize that the present invention may be embodied in a variety of other ways. The present invention includes all modifications and alternatives falling within the scope of the present invention.</p><p>The principle and operation of a USB flash device and system according to the present invention will be better understood with reference to the drawings and the accompanying description, which are given for purposes of explanation only and not limitation. </p><p>Referring to the present drawings, FIG. 5 is a structural block diagram of main components of a flash memory device and system according to the present invention. The flash memory system 42 includes a host platform 44 as shown. The host platform 44 operates the USB flash device 46 as a non-volatile storage space.</p><p>The host platform 44 is connected to a USB flash device 46 in accordance with the present invention via a USB cable 48 . Host platform 44 connects to USB cable 48 via USB host connector 50 , while USB flash device 46 connects to USB cable 48 via USB flash device connector 52 . The host platform 44 features a USB host controller 54 that controls and manages all USB transfers on the USB bus.</p><p>The USB flash device 46 controls the other components of the USB flash device 46 and provides an interface to the USB flash device 46 to a USB bus, a USB flash device connector 52 , and at least one flash memory module 58 . ) to provide a USB flash device controller 56 is characterized. The flash memory modules 58 are preferably an array of flash memory modules 58 in which data is stored.</p><p>Whenever a USB flash device 46 is connected to the host platform 44, a standard USB enumeration process occurs. In this process, the host platform 44 configures a USB flash device 46 and a mode for communicating with the USB flash device 46 . Although there are any different ways of configuring the USB flash device 46, for purposes of clarity and not limitation, the present invention provides that the host platform 44 connects to the USB flash device 46 through an endpoint. Methods for issuing requests and commands are described in more detail below. The host platform 44 queries the USB flash device 46 through another endpoint to change its state, and receives the relevant packet if any such packets are waiting to be received.</p><p>The host platform 44 requests service from the USB flash device 46 by sending a request packet to the USB host controller 54 . The USB host controller 54 transmits the packet over the USB cable 48 . When the USB flash device 46 is a device on the endpoint of the requests, these requests are received by the USB flash device controller 56 . The USB flash device controller 56 then performs various operations such as reading, writing, and erasing data to or from the flash memory module 58 or supports basic USB functions such as device enumeration and configuration. do. The USB flash device controller 56 uses the control line 60 to control the power of the flash memory module 58 through various other signals such as, for example, chip enable and read and write signals. 58) to control the power. The flash memory module 58 is also connected to the USB flash device controller 56 by an address/data bus 62 . Address/data bus 62 transports commands that execute read, write or erase commands on flash memory module 58 as well as addresses and data for those commands defined by the manufacturer of flash memory module 58 .</p><p>In order for the USB flash device 46 to notify the host platform 44 of the status and results for different operations required by the host platform 44, the USB flash device 46 uses a "status endpoint" to to send Following this procedure, the host platform 44 checks (polls) the status packet, and the USB flash device 46 returns an empty packet if there is no packet for a new status message, or alternatively the status packet itself. bring it back</p><p>A more detailed structure of the functional components of the USB flash device 46 is shown in FIG. 6 . USB flash device 46 includes a physical and electrical interface defined by the USB standard, shown herein as a USB flash device connector 52 and connector interface 64 . USB flash device connector 52 receives an electrical signal from a USB cable 48 that carries electrical signals from a host controller (not shown). These signals then pass through the connector interface 64 . Every millisecond, a USB frame is transferred on a bus defined as USB, so that a packet can be sent to the USB flash device 46 .</p><p>The connector interface 64 then receives these packets via the first interface component, which is the combined physical and logical interface 66 . Functional interface 68 is specifically designed to receive token packets, as defined in the USB specification and described with respect to FIG. 1 . These token packets relate only to the specific functional aspect of the USB flash device 46 required for the USB standard, and not to the specific application of the USB flash device 46 as a flash disk according to the present invention. These token packets and each of these return data packets allow the USB host controller 54 (not shown) and host platform 44 (not shown) to identify the USB flash device 46 and allocate the resources to the USB flash device 46. to allocate on the bus. Accordingly, the functional interface 68 only supports the USB functions required for identification and registration of the USB flash device 46 on the USB bus.</p><p>The USB flash device 46 also features an application packet extractor 70 that extracts commands and application data from the USB application packet, so that the application packet extractor 70 only supports applications related to the packet. Any requests to USB flash device 46 by host platform 44 (not shown) in the form of identifying, reading, writing, and erasing commands are then interpreted by application command interpreter 72 . For any command containing address or data, such as write, read, and erase commands, address resolution module 74 translates addresses from logical address space to physical address space. The host platform 44 (not shown) relates to a linear address space of logical addresses, while the USB flash device 46 comprises at least one and preferably a plurality of flash modules 58, each flash module having a physical address. have space Thus, the translation must be performed between the logical address space of the host platform 44 (not shown) and the physical address space or in the space of the USB flash device 46 . There are many ways of implementing such a transformation suitable for the present invention. One embodiment of a suitable implementation of an address translation method is disclosed in U.S. Patent No. 5,404,485, which is hereby incorporated by reference, for managing flash memory as a flash disk and teaching a suitable method of operation of the present invention.</p><p>Data handler 76 handles data related to aspects of any received command and passes data to and from flash module 58 via functional interface 68 . Optionally and preferably, data handler 76 implements any error correction and detection methods. Application command interpreter 72 , data handler 76 , and address parsing module 74 all have specific flash modules 58 and the underlying memory technology to erase, read, or write desired addresses on such flash modules 58 . It operates using a log driver (MTD).</p><p>When a new status packet is available, the host platform 44 checks for a status change at the USB flash device 46 and reads the status packet from the USB flash device 46 . Using these status packets, USB flash device 46 can send to host platform 44 the results of different commands issued by host platform 44 in a request (not shown) of USB flash device 46 . have. For example, the Read Command Status Packet may be one of the available status words, such as "Access," "Error," or "Invalid Address," that allows the host platform 44 to determine the outcome of a read command (not shown). includes Similarly, the erase status packet contains a status word indicating the completion of the erase process. The Write Status Packet can be sent to the host platform regarding the outcome of the write command, for example, whether the command was successful or in error, and whether the USB flash device 46 is ready for further write requests from the host platform 44 . Used by USB flash device 46 to notify 44.</p><p>The memory technology driver or MTD 78 includes routines that typically read, write, and erase flash memory devices controlled by the controller that operates the MTD 78 . Additionally, the MTD 78 may optionally include an identification routine that recognizes the appropriate type of flash memory device for which the MTD 78 is designed, so that the MTD will be initiated to interact with a particular array of flash memory devices. In addition, the identification routine should detect the number of flash memory devices in the array, and the size of the flash memory devices in the array, including various geometric characteristics of the flash array, such as interleaving and bus width. This information then enables the host platform 44 to determine the size and address space of the storage medium. U.S. Patent No. 5,799,168, which is incorporated by reference, discloses an embodiment of such a flash device.</p><p>Using the above protocols and architectures, host platform 44 may optionally implement any application using any regular memory mapped or I/O mapped flash memory device. For example, as disclosed in the aforementioned US Pat. No. 5,404,485, the host platform 44 may provide each application with a standard block device interface, such as a magnetic storage "hard disk" drive.</p><p>According to a preferred embodiment of the present invention, the operation of a host system connected to a USB flash device according to the present invention is described with respect to identifying, programming, reading and erasing the flash device. For illustrative purposes only, and not to limit the method, an exemplary USB flash device has an array of two flash memory modules, each having a size of 64 Mbit. The address translation table resides in the flash device so that the host platform operates with logical addresses. All commands and return codes between the flash device and the host platform are transported in USB data packets and transmitted through the USB data pipe. The exact structure of packets, pipes, and timing is described in the USB specification.</p><p>The operation of an exemplary device and system in accordance with the present invention is as follows. The USB flash device is first connected to the host platform, and the USB host controller assigns an address to the USB flash device on the USB bus and also allocates resources as described in the USB specification. The USB flash device actually asks the host platform to allocate resources and needs to inform the host platform how many resources are needed. Thus, a USB flash disk can selectively support lower device speeds if the USB host platform has already allocated resources to other devices.</p><p>In addition, the USB controller negotiates with the flash modules to determine the manufacturing type and size of these modules. Next, the controller creates an identification structure holding this information as well as a translation table, and a logical address space.</p><p>After the USB host controller identifies the USB flash device, the host platform often uploads the USB client driver. The driver issues an identification request command to the USB host controller which causes the controller to send the identification data packet 80 shown in FIG. The identification packet 80 includes a PID field 22 and a checksum field 26 as described above in the background of FIG. 2 . Identification packet 80 also includes an "identify" action code in action code field 82 . The packet extractor of the USB flash device receives the identification data packet 80 and sends the opcode of the "identify" command to the application command interpreter.</p><p>In response to the "identify" command, the flash device then transmits the identification data packet 84 shown in FIG. 8 . Along with the fields shown in FIG. 7 , the identification data packet 84 contains information about the size of the flash device in the flash device size field 86 as well as a minimal erase unit that erases the flash memory in the erase unit size field 88 . Also includes information about the size of</p><p>All packets described in this embodiment are data packets transmitted only on the USB bus. Before each data packet is transmitted, a USB token packet is sent and instructs the USB controller as to the identification of the device endpoint to which the data packet should be transmitted. Upon successful reception of the packet, the USB controller issues a USB ACK packet as described in the USB specification.</p><p>Once the device driver of the host platform receives this status packet, the driver can initiate issuing write and read commands to the USB flash device using application commands. When a write request is sent, a USB data packet with a buffer containing the opcode for the "write" command, and data is sent to the USB flash device. A write data packet 90 includes a write field 92 with a "write" operation code, an ADDR field 94 with a written logical address, a LEN field 96 with a written length, and the actual data written A write data packet 90 is shown in FIG. 9 which re-includes the fields described above in FIG. 8 except that it also includes a DATA field 98 . The packet extractor extracts the opcode from the write data packet 90 and sends the code to the application command interpreter. The logical address is sent to the address resolution module which translates the logical address to a physical address on one of the flash modules. The data handler optionally computes an error correction and detection mechanism if applied to a USB flash device. Once all flash memory modules are ready, a "write" command is sent to the flash module, or optionally the module containing the physical address, which may be from one or more flash modules to the MTD module. The MTD block then issues a "write" command on the data/address bus that connects the flash module to the USB device controller. Once the operation is complete and a status packet is returned to the MTD, the result of the operation is sent to the host controller and passed to the device driver of the host platform.</p><p>When the flash controller finishes the write process, as shown in FIG. 10 , the controller signals to the host platform that the state of the USB flash memory device has changed by sending a "write status" packet 100 . Instead of data field 98 , write status packet 100 includes status field 102 . The host platform reads the status packet from the flash memory device, and from the write status packet 100 , the host platform retrieves information about the completion status of the write command by the read status field 102 . In this embodiment, the flash memory device repeats the ADDR field 94 and the LEN field 96 so that the host platform has a reference to the specific command related to the status packet 100 .</p><p>11 , the "read request" packet 104 contains the opcode for the "read" command in the read field 106 , and the logic of the desired location from which the flash controller should be read in the ADDR field 108 . Includes address. As soon as the address resolution module receives this command after the address resolution module has translated the address contained in the ADDR field 108 into a specific physical address in one of the flash elements, the flash controller issues a read command to the MTD block.</p><p>When the flash controller receives data from the flash device, after a read command is issued, or if an error occurs, the flash controller sends a signal to the host platform to instruct a new status packet to be read. The host platform issues a read request and receives a "read status" packet 110 as shown in FIG. The read status packet 110 includes the address of the read data in the ADDR field 108 as well as the length of the read data in the LEN field 112 and the data itself in the data field 114 . The read status packet 110 also features a status word in the status field 116 as the operation is complete. A read operation may be completed with a number of different status conditions, such as success, fail, error detection, invalid address, invalid length, and the like.</p><p>When the host platform needs to erase an erase unit in the flash device, the host platform issues an "erase request" packet 118 shown in FIG. 13 . This packet contains an "erased" opcode in an erase field 120 , and the logical address of the erase unit in an ADDR field 122 . Upon receiving the request, the flash controller translates the logical address into an actual erase unit address in one of the flash module's physical address spaces, and issues an erase command to the MTD block.</p><p>In general, the erase process takes more time than the read and write process. When this erasing process is completed, the controller notifies the host platform that a new status packet is ready for transmission. Next, the controller sends an "erased status" packet 124 as shown in FIG. 14 . The erase status packet 124 contains the address of the erase unit in the ADDR field 122, thereby providing a reference to the erase request to the host platform. Status upon completion of the operation is provided in status field 126 .</p>