Emulating Byte-Wise EEPROM in Sector-Wise Flash Memory
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
FLASH memory's sector-wise erasable nature limits the number of times a byte can be written efficiently, as each sector must be fully erased and rewritten, which exceeds the durability limits and requires significant memory allocation, making it difficult to emulate byte-wise programmable functionality like EEPROMs.
Innovation Solution
The proposed method organizes memory using block containers with a payload portion and a block information portion, employing functions like SUM or XOR to represent data values, allowing each block container to store multiple data values before needing to be erased, thereby increasing the number of writes per sector and reducing the frequency of sector erasure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If sector-wise erasure is used in FLASH memory to store byte-wise data, then data can be stored in FLASH memory, but the number of write operations is limited and memory space is wasted
Solution Approach 1:
The patent divides a FLASH sector into multiple blocks, where each block can independently store data for a single byte location. This segmentation allows the system to track and manage write operations at the byte level rather than sector level, enabling byte-wise programming functionality while preserving the sector-wise erasure constraint of FLASH memory.
Solution Approach 2:
The patent implements a wear-leveling mechanism that discards heavily worn blocks and recovers their capacity by redistributing data across less worn blocks. When a block reaches its write endurance limit, it is marked as invalid and its space is reallocated to other blocks, thereby extending the overall reliability and number of write operations the memory can perform.
2Ease of operation
If entire sector is erased and reprogrammed to modify a single byte, then the byte can be updated, but writing speed decreases and time is consumed
Solution Approach 1:
By segmenting the sector into multiple blocks and allowing independent management of each block, the system can update individual blocks without affecting others. This enables modification of a single byte's data block without erasing the entire sector, thereby improving writing speed while maintaining byte modification capability.
Solution Approach 2:
The patent pre-organizes data into block containers with metadata that tracks the state and validity of each block. This preliminary organization allows the system to quickly identify and update only the necessary blocks without performing full sector reads or erasures, significantly improving write operations speed.
3Adaptability or versatility
If larger memory space is allocated in FLASH to emulate EEPROM, then byte-wise functionality can be achieved, but memory efficiency decreases
Solution Approach 1:
The patent makes the FLASH memory blocks serve multiple functions: they store data, track write counts, and manage wear distribution. Each block container acts as a universal structure that can hold data for any byte location while simultaneously participating in wear-leveling operations, thereby achieving EEPROM functionality without requiring excessive additional memory space.
Solution Approach 2:
The patent merges the data storage function with the wear-management function into a unified block structure. By combining metadata about write counts and block validity directly with the data blocks, the system achieves efficient space utilization while providing full byte-wise programming functionality, eliminating the need for separate management structures.
Data Source
Figure 1~2
Figure 3
Figure 4a~4b
AI summary
Method of and system for emulating a byte-wise programmable memory in a sector-wise erasable memory (3), based on the following actions: a) dividing the sector-wise erasable memory in a plurality of sectors (36), b) dividing each of the sectors into several memory locations suitable to store containers (35), each container (35) having a header (33) and a payload portion (34), c) storing a data value relating to an application in the payload portion (34) of one of the containers (35) and header information identifying the application in the header (33) in an available container. The containers are block containers. The data portion has two or more payload values. The storing action is performed in such a way that the two or more payload values in the payload portion (34) together uniquely represent the data value.