Architecture for a universal serial bus-based pc flash disk

[0001] [Field and Background of Invention] The present invention relates to semiconductor memory devices, in particular to erasable and programmable semiconductor memory modules connected to host platforms using the USB PC bus. [0002] Erasable and programmable non-volatile storage modules (hereinafter referred to as flash memories or flash devices) are known in information storage techniques. A flash device is a non-volatile memory that includes an electrically erasable and programmable read-only memory (EEPROM) formed from flash type, floating gate transistors and is similar in function and performance to EEPROM memory. However, it has the additional function of erasing memory pages, allowing program operations in the circuit. An example of an example of such a flash device is US Pat. No. 5,799,168 (which shall be fully described in the text by reference). [0003] Flash devices have the advantage of being relatively inexpensive and consuming less power than traditional storage magnetic disks. However, in a flash device, it is practically difficult to rewrite the write area in the memory without erasing the page of the area in advance. Due to this limitation, the flash device is a typical existing operating system program because data cannot be written to that area without first erasing the memory area in the flash device that has previously written data. Are incompatible. For example, a software management system (as fully described in the text) as disclosed in US Pat. No. 5,404,485, filed March 5, 1993, is such a feature of flash memory devices. Must be handled well. [0004] Currently, flash memory devices have the second limitation that they must be fixedly mounted on the host platform or detachable using the PCMCIA (International Partnership for PC Memory Cards) interface. Both methods have the disadvantages of being difficult to use and expensive. [0005] Therefore, as a more useful example, the USB standard represented in USB standard version 1.1 (which shall be fully described in the text) will be used. The USB standard lowers manufacturing costs and lowers the form factor, making it easier for end users to use. This standard is an industrial standard encouraged by companies such as Compaq Computer, Microsoft, IBM, and Intel for computer telephony integration (CTI), consumer, and productivity-enhancing applications for PC architecture. It serves as an extension of. [0006] Criteria that define the architecture of the USB standard include ease of expansion of PC peripherals, low cost, support for transfer rates up to 12 Mb / s, and full support for real-time data in audio and compressed video. .. The standard also provides a standard interface for protocol flexibility for mixed mode isochronous data transfer and asynchronous messages, integration of general purpose equipment technology, and rapid integration into any host product. In addition, the USB standard is a single model for cable and connector mounting that isolates all details of electrical functionality, including bus terminals, from the end user. Through this standard, peripherals are self-identifying and support automatic mapping of functional parts to drivers. In addition, this standard allows all peripherals to be removable and reconfigurable. [0007] A system configured by the USB standard has three defined areas: USB interconnect, USB device and USB host platform. USB interconnection is a method in which a USB device is connected to and communicates with a host platform. Related features and elements include bus topology as a connection model between the USB device and the host platform. [0008] The physical interconnection of USB is a step-by-step star topology, with the hub at the center of each star. Each wire portion is a two-point connection between a host platform and a hub or functional unit, or between a hub connected to another hub or functional unit. [0009] Regarding the capability stack, there are data flow models and schedules as USB tasks performed at each layer in the system. A data flow model is a method of moving data over USB between a data generator and a data consumer in a system, and a schedule determines access to shared interconnects. Is. Such scheduling allows support for isochronous data transfer and eliminates arbitration overhead. [0010] USB itself is a pole bus. The host control on the host platform initiates all data transfers. Every bus transaction requires the transmission of up to 3 packets, and each transaction has the host control sending a USB packet representing the type and direction of the transaction, the address of the USB device, and the number of endpoints, based on a schedule. It starts when it happens. This packet is called a "token packet". The USB device to which the packet is destined chooses itself by decrypting the appropriate address field. In any 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 the token packet. The transaction source then sends a data packet or indicates that the transaction source has no data to transfer. Generally, the destination responds with a handshake packet indicating whether the transfer was successful. [0011] The USB data transfer model between the source and destination on the host platform and the endpoint on one device is called a "pipe". There are two types of pipes, streams and messages. Stream data does not have a USB definition structure, but message data does. In addition, pipes relate to endpoint characteristics such as data bandwidth, transfer service type, and directionality and buffer size. Most pipes occur when you configure a USB device. When a device is powered, a single message pipe, the default control pipe, is always present to provide access to configuration, state and control information about this device. [0012] The transaction schedule for the USB standard allows flow control for several stream pipes, and at the hardware level, the buffer is underrun or by using the NAK handshake, which reduces data transfer speed. Prevent overruns. In the NAK handshake, the transaction is repeated when bus time is available. The flow control mechanism allows the construction of flexible schedules to accommodate the non-uniform mixed parallel services of stream pipes. Therefore, a large number of stream pipes can be used with packets of different sizes at different intervals. [0013] The USB standard, as described above, has three main packet types, including token packets, data packets and handshake packets. Examples of each type of packet are shown in FIGS. 1 to 3 showing the background technology. Figure 4 schematically illustrates a model USB device in the background technology. [0014] Background Technology Token packet 10 shown in FIG. 1 has a PID (packet identification) field 12 that specifies one of the three packet types: in, out, or setup. If you specify an in-packet type in PID field 12, the data transaction is defined from the functional unit to the host platform, and if you specify an out or setup packet type in PID field 12, the data transaction is a host platform. Is defined to the functional part. [0015] The ADDR field 14 specifies the address and the ENDP field 16 specifies the endpoint for token packet 10. In PID field 12, token packet 10 is out packet type or setup. For out and setup transactions designated as packet type, ADDR field 14 and ENDP field 16 are endpoints for receiving the next data packet shown in Figure 2 following token packet 10. To identify. For in-transactions where token packet 10 is specified as in-packet type in PID field 12, ADDR field 14 and ENDP field 16 indicate which endpoint sends the data packet. To clarify. CRC5 field 18 contains a checksum to determine that token packet 10 was received without compromising its original form. Since only the host platform can issue token packet 10, token packet 10 provides transmission control for subsequent data packets. [0016] As shown in FIG. 2 of the background technology, the conventional USB data packet 20 also has a PID (packet identification) field 22 for identifying the type of data packet. The data packet 20 also has a data field 24 to optionally include data and a CRC field 26 to include the checksum described above. [0017] FIG. 3 of the background technology shows a conventional USB handshake packet 28 with only the PID (packet identification) field 30. The handshake packet 28 is used to report the status of a data transaction and can return values indicating successful data reception, acceptance or rejection of commands, flow control and shutdown status. A transaction type that simply supports flow control can return handshake packet 28. The handshake packet 28 is always returned at the transaction handshake stage and may be returned in place of the data packet 20 at the transaction data stage. [0018] These three different types of packets are exchanged at various stages of a transaction involving a USB device. A schematic block diagram of the functional blocks of a typical USB device 32 is shown in FIG. 4 as a schematic USB device of the background technology. The USB device 32 typically includes a USB electrical interface 34 consisting of a cable and a connector, which is a physical interface for transmitting and receiving electrical signals conforming to the above USB specifications. The signal passes through a logical interface 36 that includes one or more buffers, a device address decoder that decodes the address of the signal source device, and a SYNC field synchronizer that synchronizes the signal. The information and structure required for the general management of the USB device 32 as a USB device is stored within the USB class control and enumeration engine 38. Functions and Equipment The engine 40, also referred to as an "application," controls and manages specific functions and characteristics of the general USB device 32. In addition, the function and equipment engine 40 consumes and produces most of the data on the USB bus. [0019] However, the relationships between different entities within the general USB device 32 are not defined by the USB specification. Rather, the USB specification merely represents a requirement for packets and for the electrical and physical connectivity between the general USB device 32 and the bus. Therefore, the connections and relationships shown in FIG. 4 of the background technology are merely one of the examples that satisfy the requirements of the USB specifications. Therefore, certain devices that meet the USB specification must have a specially defined and represented architecture. [0020] Unfortunately, such an architecture allows one or more flash memory devices to form part of a USB system on a host platform by connecting the flash memory device to a bus defined by the USB specification. -It does not exist for flash memory devices including modules. For example, US Pat. No. 5,799,168 does not suggest such an example for a flash device. As mentioned earlier, such an architecture is particularly useful for a number of reasons, including low cost, ease of use, and end-user comprehension. [0021] [0021] Therefore, there is a need for an architecture that is compatible with the USB system and defines and expresses a flash memory device that conforms to the USB specifications. According to such an architecture, the flash memory device is very useful because it is on a USB-defined bus and can communicate with the host platform via this bus. [0022] [Structure of the Invention] The present invention relates to one or more flash modules in which the flash memory is mapped in the address space of an ASIC, or a flash memory device including a controller having a USB-defined electrical interface and a USB-defined logical interface. This controller or ASIC (hereinafter referred to as "control") supports USB functions according to the USB standard, so it can be enumerated on the USB bus, and it can be enumerated on the USB endpoint via a USB pipe. You can send and receive data. The controller also supports the function and control of the flash memory device and the processing of commands and data packets from the host controller. The host control uses one of several standard or proprietary possible protocols to inform the USB flash control of the next command to execute. Therefore, the entire device acts as a dynamically removable non-volatile storage device for the host platform. [0023] According to the present invention, a USB flash memory device connected to a USB-defined bus is provided. This flash memory device (a) connects to at least one flash memory module for storing data and (b) connects to a USB-defined bus and sends packets to the USB-defined bus, and from the USB-defined bus. It consists of a USB connector for receiving packets and (c) a USB controller that controls at least one flash memory module and controls the USB connector in response to at least one packet received from a USB-defined bus. , Data is written and read to at least one flash memory module. [0024] Hereinafter, the term "computer" refers to the following without limitation. PC (PC) with operating system such as DOS, Windows (TM), OS / 2 (TM) or Linux, Macintosh (TM) computer, computer with Java (TM) OS as operating system, Sun Micro Graphics workstations such as Systems (TM) and Silicon Graphics (TM) computers, and several versions of UNIX operating systems such as Sun Microsystems (TM) AIX (TM) or Solaris (TM). Other computers with, or as embedded systems, mobile phones with other known available operating systems, including operating systems such as Windows CE (TM), hand-held computers, palm top calculations A device, and other computers that can be connected to a network. Hereinafter, the term "Windows (TM)" is not limited to Windows 95 (TM), Windows 3.x (TM) (x is an integer such as "1"), Windows NT (TM), Windows 98 (TM). ) , Windows CE (TM), and Microsoft (Seattle, WA, USA) show upgraded versions of these operating systems. [0025] BEST MODE FOR CARRYING OUT THE INVENTION The present invention relates to a flash memory device comprising an ASIC or one or more flash modules in which a flash memory is mapped into the address space of a controller having a USB-defined electrical interface and a USB-defined logical interface. This controller or ASIC (hereinafter referred to as "control") supports the USB function according to the USB standard. For this reason, it supports enumeration on the USB bus and receiving and transmitting data to and from the USB endpoint on the USB pipe. The controller also supports the function and control of the flash memory device and the processing of commands and data packets from the host controller. The host controller uses one of several standard or proprietary protocols to send the next command to the USB flash controller. Therefore, the entire device operates as a removable non-volatile storage device for the host platform. [0026] The present invention can be modified in various ways and can be embodied using many alternative forms, but examples are shown in the drawings and will be described in detail below. It is clear to those with ordinary skills in the art that the invention can be embodied in a variety of other ways. The intent is to address all modifications and alternatives that fall within the scope of the invention. [0027] The principles and operations of the USB flash device and system according to the present invention can be understood from the drawings and the description, but these drawings are shown for the purpose of explanation only and are not intended to be limited. [0028] Now, refer to the drawing. FIG. 5 is a schematic block diagram of the main components of the flash memory device and system according to the present invention. As shown in the figure, the flash memory system 42 includes a host platform 44. The host platform 44 operates the USB flash device 46 as a non-volatile storage space. [0029] The host platform 44 is connected to the USB flash device 46 according to the present invention via a USB cable 48. The host platform 44 is connected to the USB cable 48 via the USB host connector 50, while the USB flash device 46 is connected via the USB flash device connector 52. The host platform 44 includes a USB host controller 54 for controlling and processing all USB transfers on the USB bus. [0030] The USB flash device 46 includes a USB flash device controller 56 for controlling other elements of the USB flash device 46 and providing an interface to the USB bus of the USB flash device 46, and a USB flash device connector 52. Includes at least one flash memory module 58. The flash memory module 58 is preferably an array of a plurality of flash memory modules 58 in which data is stored. [0031] When the USB flash device 46 is connected to the host platform 44, the standard USB enumeration process begins. In this process, the host platform 44 recognizes the USB flash device 46 and forms a communication mode with the USB flash device 46. There are many different ways to configure the USB flash device 46, but for the sake of clarity, the host platform 44 issues commands and requests to the USB flash device 46 via the endpoint, unintentionally intended to limit it. The present invention will be described in detail below with respect to the method of producing. The host platform 44 queries the USB flash device 46 via another endpoint for state changes and receives any associated packets to be received. [0032] 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 sends a packet over the USB cable 48. If the USB flash device 46 is a device on the endpoint of this request, these requests are received by the USB flash device controller 56. Next, the USB flash device controller 56 performs various operations such as reading, writing, or erasing data from the flash memory module 58 or the flash memory module 58, or enumerating and configuring devices. Supports basic USB functions. The USB flash device controller 56 uses a control line 60 to control the output of the flash memory module 58, and also via various other signals such as chip enable and read / write signals. -Control module 58. The flash memory module 58 is also connected to the USB flash device controller 56 by the address / data bus 62. The address / data bus 62 transfers read, write, or erase commands to the flash memory module 58 and addresses and data for these commands defined by the manufacturer of the flash memory module 58. [0033] The USB flash device 46 uses a "state endpoint" to transmit state packets to inform the host platform 44 of the results and states of the various operations requested by the host platform 44. In this process, the host platform 44 checks for state packets (polling), and the USB flash device 46 either empty packets if there are no new state message packets, or optionally the state packets themselves. return it. [0034] A more detailed structure of the functional elements of the USB flash device 46 is shown in FIG. The USB flash device 46 includes a physical and electrical interface defined in the USB standard, herein as USB flash device connector 52 and connector interface 64. The USB flash device connector 52 receives an electrical signal from a USB cable 48 that carries the electrical signal from the host controller (not shown). These signals then pass through connector interface 64. Every millisecond, the USB frame is carried over the USB-defined bus, allowing packets to be sent to the USB flash device 46. [0035] These packets are received by the connector interface 64 via the first interface component, which is the physical and logical interface 66. Functional interface 68 is specially designed to receive the token packets defined in the USB specification, as described earlier with respect to FIG. These token packets relate only to the specific function of the USB flash device 46 as required by the USB standard, and have nothing to do with the specific use of the USB flash device 46 as a flash disk according to the present invention. There is no such thing. In these token packets and the corresponding returned data packets, the USB host controller 54 (not shown) and the host platform 44 (not shown) identify the USB flash device 46 on the USB bus. , And allow resources to be allocated to the USB flash device 46. Therefore, the functional interface 68 merely supports the USB functions required to identify and register the USB flash device 46 on the USB bus. [0036] The USB flash device 46 also includes an application packet extractor 70 that extracts application data and commands from a USB application packet. Therefore, the application packet extractor 70 only supports packets related to the application. The request in the form of read, write, identify and erase commands to the USB flash device 46 by the host platform 44 (not shown) is then interpreted by the application command interpreter 72. For data or address-related commands such as read, write, and erase commands, the address resolver module 74 interprets the address from the logical address space to the physical address space. Although the host platform 44 (not shown) involves a linear address space for logical addresses, the USB flash device 46 consists of at least one, and preferably multiple, flash modules 58, each with a physical address space. Therefore, a replacement must be made between the logical address space of the host platform 44 (not shown) and the physical address space of the USB flash device 46. There are many methods suitable for the present invention for realizing such a replacement. One example of a suitable embodiment of the address replacement method is described in US Pat. No. 5,404,485, which is described herein with reference to the above, in which the flash as a flash disk suitable for the operation of the present invention. It shows how to manage memory. [0037] The data handler 76 processes the data-related portion of the received command and transfers the data to and from the flash module 58 via the functional interface 68. As an option, the data handler 76 preferably performs error correction and detection. The application command interpreter 72, the data handler 76 and the address resolver module 74 all work with the underlying memory technology driver (MTD) 78 on a particular flash module 58 and its flash module 58. Write, read, or erase to the desired address in. [0038] The host platform 44 examines the state change of the USB flash device 46 and reads the state packet from the USB flash device 46 if a new state packet is available. Using these state packets, the USB flash device 46 can transmit the results of various commands issued by the host platform 44 as a request (not shown) to the host platform 44. For example, a read command state packet contains one of the available state words such as "success", "error" or "invalid address", and the host platform 44 outputs the result of the read command (not shown). It is possible to judge. Similarly, the erased state packet contains a state word indicating the completion of the erased process. The write state packet is used by the USB flash device 46 to inform the host platform 44 of the result of the write command, for example, the command is successful or incorrect, and the USB flash device 46 is the host. Notify if you are ready for additional write requests from platform 44. [0039] A memory technology driver, or MTD78, typically includes routines for reading, writing, and erasing flash memory devices controlled by the controls that operate the MTD78. In addition, the MTD78 optionally includes an identification routine for the MTD78 to recognize the correct type of flash memory device designed. In this way, the controller can determine which MTD to activate when interacting with a particular flash memory device array. In addition, the identification routine can detect various characteristics of the flash array pattern, such as the size of the flash memory device array, including the number of flash memory devices in the array, and interleaving and bus width. This information will later be used by the host platform 44 to determine the address space and size of the storage medium. U.S. Pat. No. 5,799,168, mentioned above as a reference, discloses an example of such an MTD for a flash device. [0040] By using the above protocols and architectures, the host platform 44 can optionally run applications that can be embodied in flash memory devices with regularly mapped memory or I / O. For example, as disclosed in US Pat. No. 5,404,485 previously mentioned, the host platform 44 can provide a standard block device interface for applications such as magnetic storage media, "hard disk" drives, and the like. [0041] As a preferred embodiment of the present invention, the operation of the host system connected to the USB flash device according to the present invention will be described with respect to the process of identifying, programming, reading, and erasing the flash device. For purposes of illustration, an exemplary USB flash device with an array of two flash memory modules, each of which is 64 megabits in size, is shown without intention of limitation. The host platform operates with logical addresses because the flash device contains an address translation table. All commands and return codes between the flash unit and the host platform are carried in USB data packets and transferred over the USB data pipe. The exact structure, pipe and timing of the packet is described in the USB specification. [0042] The operation of the exemplary device and system according to the present invention is as follows. First, when the USB flash device is connected to the host platform, the USB host controller assigns an address to the USB flash device on the USB bus. Also, allocate the resources described in the USB specification. In reality, the USB flash device asks the host platform to allocate these resources, but at this point it must inform the host platform how much resources it needs. Therefore, if the USB host platform has already allocated resources to other devices, the USB flash disk can optionally support slower device speeds. [0043] The USB controller also negotiates with the flash modules to determine the size and manufacturing type of these modules. The control then creates an identification structure that holds this information, as well as a translation table and logical address space. [0044] After the USB host controller identifies the USB flash device, the host platform typically uploads the USB client driver. The driver issues an identification request command to the USB host controller, causing the controller to send the identification data packet 80 shown in FIG. As previously described for FIG. 2 of the background technology, the identification packet 80 includes a PID field 22 and a checksum field 26. The identification packet 80 also includes an "identification" operation code in the operation code field 82. The packet extractor of the USB flash device receives the identification data packet 80 and transfers the operation code of the "identification" command to the application command interpreter. [0045] In response to the "identify" command, the flash device sends an identification data packet 84, as shown in FIG. In addition to the fields shown in Figure 7, the identification data packet 84 contains information about the size of the flash device in the flash device size field 86, and the minimum erase unit for erasing the flash memory in the erase unit size field 88. Contains size information. [0046] All packets described in this example are only data packets transmitted over the USB bus. Before each data packet is sent, a USB token packet is sent, telling the USB controller the ID of the device endpoint to which the data packet is destined. If the packet is successfully received, the USB controller issues a USBACK packet as described in the USB specification. [0047] When the host platform device driver receives this state packet, the driver can use application commands to issue read / write commands to the USB flash device. When a write request is sent, the USB data packet with the arithmetic code for the "write" command and the buffer containing the data are transferred to the USB flash device. The write data packet 90 is shown in FIG. This also includes the fields shown in Figure 8 above, with the following differences: The write data packet 90 has a write field 92 with a "write" arithmetic code, an ADDR field 94 to write a logical address, a LEN field 96 with a write length, and a data field 98 containing the actual data to write. The packet extractor extracts the arithmetic code from the write data packet 90 and transfers this code to the application command interpreter. The logical address is transferred on one flash module to the address resolver module that translates this logical address into a physical address. If a USB flash device is required, the data handler optionally calculates an error correction and detection mechanism. When all flash memory modules are ready, a "write" command is sent to a single flash module or multiple modules containing physical addresses. The physical address may optionally extend across one or more flash modules to the MTD block. The MTD block then issues a "write" command on the data / address bus that connects the flash module to the USB device controller. When the operation is complete and the status packet is returned to the MTD, the result of the operation is sent to the host control and passed to the device driver on the host platform. [0048] When the flash controller finishes the write process, the controller notifies the host platform that the state of the USB flash memory device has changed by sending the "write state" packet 100 shown in FIG. Write state packet 100 includes state field 102 instead of data field 98. The host platform retrieves information about the completion status of the write command by reading the status packet from the write status packet 100 and reading the status field 102 from the flash memory device. In this example, the flash memory device repeats ADDR field 94 and LEN field 96 so that the host platform can refer to specific commands for state packet 100. [0049] As shown in FIG. 11, the "read request" packet 104 contains the arithmetic code for the "read" command in the read field 106 and the logical address of the desired position that the flash control should read in the ADDR field 108. Including. Upon receiving this command, the address resolver module translates the address contained within the ADDR field 108 into a specific physical address within a flash component, after which the flash control issues a read command to the MTD block. .. [0050] The flash controller sends a signal to the host platform after a read command is issued, or in the event of an error, indicating that the flash controller needs to read a new state packet. Receive data from. The host platform issues a read request and receives the "read state" packet 110 shown in FIG. The read state packet 110 contains the address of the read data in the ADDR field 108, the length of the read data in the LEN field 112, and the data itself in the data field 114. Further, the read state packet 110 includes a state word in the state field 116, and the operation is completed accordingly. The read operation completes in many different states such as success, failure, error detection, invalid address, invalid length, and so on. [0051] If the host platform needs to erase one erase unit in the flash unit, the host platform issues an "erase request" packet 118, as shown in FIG. This packet contains the "erase" arithmetic code in the erase field 120 and the logical address of the erase unit in the ADDR field 122. Upon receiving such a request, the flash controller translates the logical address into the physical address of the erase unit located in one of the physical address spaces of the flash module, and issues an erase command to the MTD block. [0052] The erase process generally requires more time than the read or write process. Therefore, when this erasure process is complete, the control informs the host platform that it is ready to send a new state packet. The controller then sends the "erased state" packet 124, shown in FIG. Erase state packet 124 contains the address of the erase unit in the ADDR field 122, which provides the host platform with reference information for the erase request. The completed state of the operation is provided in the state field 126. The above description is intended merely as an example, and it is clear that many other examples are possible within the scope of the present invention. [Simple explanation of drawings] FIG. 1 is a schematic block diagram of a USB token packet structure based on background technology. FIG. 2 is a schematic block diagram of a USB data packet structure based on background technology. FIG. 3 is a schematic block diagram of a USB handshake data packet structure based on background technology. FIG. 4 is a schematic block diagram of a USB device using exemplary background technology. FIG. 5 is a schematic block diagram of a system having the function of a flash USB device according to the present invention. FIG. 6 is a schematic block diagram of a USB flash disk. FIG. 7 is a schematic block diagram of a flash identification request packet. FIG. 8 is a schematic block diagram of a flash identification state packet. FIG. 9 is a schematic block diagram of a flash write request packet. FIG. 10 is a schematic block diagram of a flash write state packet. FIG. 11 is a schematic block diagram of a flash read request packet. FIG. 12 is a schematic block diagram of a flash read state packet. FIG. 13 is a schematic block diagram of a flash erase request packet. FIG. 14 is a schematic block diagram of a flash erased state packet.