2.3 Retention Relaxation for Flash Storage
2.3.2 Benefits of Retention Relaxation
In this section, we elaborate on the benefits of Retention Relaxation from two perspectives
— improving write speed and improving ECC cost-performance. The analysis considers flash cycled to the maximum rated endurance (i.e., 100% wearout) with one-year data retention capability [64]. Since flash’s reliability typically degrades monotonically in terms of P/E cycles, considering the maximum rated endurance is conservative for the following benefit evaluation. In other words, flash in its early lifespan has more headroom for optimization.
Improving Write Speed
As presented earlier, flash uses the ISPP scheme to incrementally program memory cells.
The Vth step increment, ∆VP, directly affects write speed and retention capability. Write speed is proportional to ∆VP because with larger ∆VP, less steps are required during the ISPP procedure. On the other hand, retention capability decreases as ∆VP gets larger be-cause large ∆VP widens Vth distributions and reduces the margin for tolerating retention errors.
Algorithm 1 shows our procedure to quantitatively evaluate flash’s write speedup if retention requirements are reduced. The analysis is based on the extended flash model presented in Section 2.3.1 with all the typical and corner cases. We first enlarge ∆VP by various ratios between 1× to 3×, thereby, speeding up flash writes proportionately. For each ∆VP setting, we evaluate RBER(t) at different retention time between zero and one year to find the maximum t within which RBER(t) remain within the capability of ECC (CBCH).
Figure 2.7 plots the write speedup vs. retention requirement. The typical case (the black line) and corner cases (the gray dashed lines) are all plotted. For the typical case, if retention requirement is relaxed from one year to 10 weeks, 1.86× speedup for flash page write is achievable; if retention requirement is relaxed to 2 weeks, the speedup is 2.33×.
Furthermore, the speedup for the corner cases are close to the typical case. This means the
Algorithm 1 Write speedup vs. retention requirement
1: CBCH = 4.5 × 10−4
2: for all typical and corner cases do
3: for VoltageRatio = 1 to 3 step = 0.01 do 4: Enlarge ∆VP by VoltageRatio times 5: WriteSpeedUp = VoltageRatio 6: for Time t = 0 to 1 year step = δ do
7: Find RBER(t) according to σlow(t) and α(t) 8: end for
9: DataRetention = max{t:RBER(t) ≤ CBCH} 10: plot (DataRetention, WriteSpeedUp)
11: end for 12: end for
Data Retention (Year)
NAND Flash Write Speedup
Retention Speedup 1 year 1×
10 weeks 1.86×
2 weeks 2.33×
2 weeks 10 weeks
Typical case Corner cases
Figure 2.7: Flash page write speedup vs. retention requirement
speedup numbers are not very sensitive to the values of the parameters we obtain using parameter fitting.
Improving ECC Cost-Performance
ECC design is an emerging, critical issue in flash storage. Nowadays, flash storage heavily relies on BCH codes to handle the RBER. Unfortunately, BCH codes become inefficient once the RBER of flash reaches 10−3 [88]. Recent flash exhibits an one-year RBER up to 4.5 × 10−4. As the density of flash continues to increase, the one-year RBER of future flash will raise and inevitably exceed 10−3. Therefore, BCH codes will soon become inapplicable in the near future.
LDPC codes are promising ECCs for future flash storage [41, 109, 151]. The main ad-vantage of LDPC is that they are suitable to handle an RBER greater than 10−3. However, LDPC incurs much higher encoding complexity than BCH does [80, 92]. For example, an optimized LDPC encoder [163] consumes 3.9 M bits of memory and 11.4 k FPGA Logic Elements to offer 45 MB/s throughput. To sustain write throughput of high-performance flash storage, e.g., 1 GB/s ones [48], high-throughput LDPC encoders are a must; oth-erwise the LDPC encoders tend to become the throughput bottleneck. High-throughput LDPC encoders lead to high hardware cost because hardware parallelization is one basic approach to increase the throughput of LDPC encoders [90]. In this work, we exploit Retention Relaxation to alleviate this dilemma to reach a better cost-performance design point. Specifically, since Retention Relaxation only needs to handle a reduced number of retention errors, BCH codes are still sufficient to protect data even if the one-year RBER of flash reaches or exceeds 10−3[88].
Algorithm 2 shows our procedure to analyze the achievable retention capability of BCH codes with error-correction capability of 24 bits per 1080 bytes considering future flash with various one-year RBERs. We assume that RBER(t) follows the power-law trend described in Section 2.3.1. We vary RBER(1 year) from 4.5 × 10−4 to 1 × 10−1 and derive the corresponding write error rate (RBERwrite) and retention error increment
RBER at 1 Year
1-Year RBER Retention 4.5E-4 1 year 3.5E-3 10 weeks 2.2E-2 2 weeks
Typical case Corner cases
2 weeks10 weeks
Data Retention for Baseline BCH (Year)
Figure 2.8: Retention capability of 24 error correction per 1080 bytes BCH codes
per unit of time (RBERretention). The achievable retention capability is the time when RBER exceeds 4.5 × 10−4, i.e., the capability of the target BCH codes.
Algorithm 2 Retention capability achievable by BCH codes (24-bit error correction per 1080 bytes) vs. one-year RBER
1: tmax = 1 year 2: CBCH = 4.5 × 10−4
3: for all typical and corner cases do
4: for RBER(tmax) = 4.5 × 10−4to 1 × 10−1step = δ do 5: RBERwrite= RBER(tC max)
write
6: RBERretention= (RBER(tmaxt )−RBERwrite)
maxm
7: RetentionTime = (CBCHRBER−RBERwrite
retention )m1 8: plot (RBER(tmax), RetentionTime) 9: end for
10: end for
Figure 2.8 depicts the analyzing results. The black line stands for the typical case, and the gray dashed lines stand for the corner cases. For the typical case, the analyzed BCH codes can retain data for 10 weeks even if RBER(1 year) exceeds 10−3and reaches 3.5×
10−3. The analyzed BCH codes can still retain data for 2 weeks even if RBER(1 year) of future flash reaches 2.2 × 10−2. The corner cases exhibit similar trends.
Time (A.U.)
a b b a c a
0 1 2 3 4 5 6 7
3 1 ? 2 ?
Retention requirement LBA written
?
Figure 2.9: Retention requirements in a write stream