Abstract
Experimental results indicate that the conventional program suspend scheme in 3D NAND flash memory chip can generate unexpected additional read fail bits and reduce the reliability of 3D NAND flash memory. These extra read fail bits are observed when the program suspend command is issued during the program stage, and particularly, they become more obvious as the delay time between program suspend operation and other following operations exceeds tens of milliseconds. By analyzing the waveform of conventional program suspend scheme, it is suggested that the unexpected extra read fail bits are caused by the different occupancy of grain boundary traps (GBTs) in the polycrystalline silicon (poly-Si) channel during the idle time after the program suspend operation. Accordingly, a novel program suspend scheme is proposed by adding a “stabilizing” pulse immediately after the program stage. Silicon experimental data show that the proposed scheme can effectively limit the read fail bit count (FBC) to a normal range, thus improving the reliability of 3D NAND flash memory significantly.
Highlights
OVER the past decade, the demand for NAND flash memory in mobile devices and solid state drives (SSDs) has grown rapidly [1], owing to its unprecedented advantages of low cost and large capacity
Before introducing conventional program suspend scheme, an example for a block structure of 3D NAND flash is shown in Fig. 1(a), where M strings are shared by one bitline
In work [20], it has been reported that the channel potential after the verify stage is more negative, which means when the program suspend command is issued during the program stage, the grain boundary traps (GBTs) detrapping influence should be more than during the verify stage, in line with our experimental results
Summary
Abstract—Experimental results indicate that the conventional program suspend scheme in 3D NAND flash memory chip can generate unexpected additional read fail bits and reduce the reliability of 3D NAND flash memory These extra read fail bits are observed when the program suspend command is issued during the program stage, and they become more obvious as the delay time between program suspend operation and other following operations exceeds tens of milliseconds.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
