809 Hardware EEPROM Wear-Leveling Controller
809 : Hardware EEPROM Wear-Leveling Controller
- Author: Olonade Kelvin
- Description: Implements the proven Start-Gap wear-leveling algorithm, the same technique used in commercial 3D-XPoint and phase-change memories, enhanced with a 2-round Feistel address scrambler for strong resistance against wear-leveling attacks. Additional features include Hamming(6,3) single-error correction on persistent state, automatic bad-block retirement, saturating wear counters, and an in-band telemetry port for monitoring.
- GitHub repository
- Open in 3D viewer
- Clock: 5000000 Hz
Hardware EEPROM Wear-Leveling Controller
A digital IP that transparently spreads write operations across physical memory blocks, extending the lifetime of external EEPROMs and flash memories in edge devices.
How it works
The controller maintains two on‑chip tables:
- Mapping table: logical block → physical block (8 entries)
- Wear counter table: 16‑bit write count per physical block
On every write_commit command the wear counter of the addressed physical block is incremented. If the difference between that counter and the minimum among all physical blocks exceeds a fixed threshold (4), a remap is triggered. The logical block owning the least‑worn physical block is swapped with the currently written logical block. The host is informed via move_request and must copy the data before acknowledging with move_ack.
All operations are pipelined through a purely digital finite‑state machine that runs in a few clock cycles, making the block easy to integrate into any SPI or I²C memory controller.
How to test
- Apply reset (
rst_nlow) for at least 100ns. - Verify identity mapping by sending
read_reqfor every logical address. - Issue repeated
write_req/write_commitpairs to the same logical block while monitoringbusyandmove_request. - When
move_requestasserts, read the source (uo_out[2:0]) and destination (uio_out[2:0]) physical addresses, copy the data externally, then assertmove_ack. - Confirm that after multiple writes the logical‑to‑physical mapping has changed, and that no physical block accumulates significantly more writes than others.
- Use the provided Cocotb testbench (
test/test.py) for automated verification.
IO
| # | Input | Output | Bidirectional |
|---|---|---|---|
| 0 | logical block address bit 0 | physical block address bit 0 | move_dest / telem_data bit 0 |
| 1 | logical block address bit 1 | physical block address bit 1 | move_dest / telem_data bit 1 |
| 2 | logical block address bit 2 | physical block address bit 2 | move_dest / telem_data bit 2 |
| 3 | command bit 0 (cmd[0]) | busy — controller is processing | telem_data bit 3 |
| 4 | command bit 1 (cmd[1]) 00=read 01=write 10=commit 11=telem | move_req — request external agent to migrate block | telem_data bit 4 |
| 5 | move_ack — external agent confirms data-copy complete | ecc_error — single-bit ECC correction occurred (informational) | telem_data bit 5 |
| 6 | telemetry select bit 0 | block_retired — currently addressed physical block is retired | telem_data bit 6 |
| 7 | telemetry select bit 1 00=skew 01=total_lo 10=total_hi | telem_valid — telemetry byte on uio_out is valid | telem_data bit 7 |