Browse Prior Art Database

Method for simultaneous read-while-write in flash memory

IP.com Disclosure Number: IPCOM000012941D
Publication Date: 2003-Jun-11
Document File: 4 page(s) / 139K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for simultaneous read-while-write in flash memory. Benefits include improved performance.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Method for simultaneous read-while-write in flash memory

Disclosed is a method for simultaneous read-while-write in flash memory. Benefits include improved performance.

Background

        � � � � � Flash memory typically has a much longer erase time than read time. The relative time difference in the flash operations has resulted in the development of read-while-write protocols. They enable code to apparently be executed from the flash device while an erase operation progresses.

        � � � � � A software read-while-write appears to execute code from the flash device while a write operation is in process. The key to the software read-while-write protocol is the capability to poll interrupts, suspend the flash if there is a interrupt pending, put the array back into read array and enable the interrupt code to be executed directly from flash. Software read-while-write is inefficient due to the amount of time spent polling interrupts and the additional latency associated with the flash suspend.

        � � � � � Hardware read-while-write enables an erase operation within a partition to complete uninterrupted while code is executed from the other partitions. Hardware read-while-write is expensive to implement with a small partition granularity. As partition granularity increases, the probability that the code/data ratio exactly matches the partition boundaries is small.

        � � � � � An example is the design of a 32 MB flash device with 8-4 MB partitions (see Figure 1). To use hardware read-while-write, the code footprint is required to match 4-MB increments. If the code footprint is actually 26 MB, the system designer has the option of using software read-while-write, which is inefficient for the application response. Alternatively, 2 MB of the second to last last 4 MB partition can be wasted to preserve the hardware read-while-write operation. As the partition sizes grow, the processing cost of read-while-write can become prohibitive.

Description

        � � � � � The disclosed method describes a modification to a flash device that enables hardware read-while-write functionality in all code+data partitions and enables software read-while-write operation in the code and data partition.

Advantages

        � � � � � The disclosed method provides advantages, in...