Micron bouwt flashgeheugen met foutcorrectie
Geheugenfabrikant Micron Technologies heeft een nieuw type flashgeheugen ontwikkeld dat foutcorrectie in de chips integreert. Dit moet een oplossing bieden voor de toename van fouten die inherent zijn aan kleine productieprocedés.
Micron Technologies heeft de nieuwe nand-techniek ClearNand gedoopt. De normale of Standard-versie van deze techniek moet zijn weg vinden in nand-geheugen dat voor consumentenproducten wordt gebruikt, terwijl een versie die Enhanced ClearNand wordt genoemd voor servergeheugen zal worden gebruikt. De beide flashgeheugens zijn per direct verkrijgbaar. Flashgeheugen voor de consumentenmarkt zal verkrijgbaar zijn in 8 tot 32GB-mlc-versies en is onder meer voor mediaspelers bedoeld.
Volgens Micron leidt de integratie van ecc tot minder belasting voor de processor van het systeem en voor de geheugencontroller. Die zouden het steeds drukker krijgen met het herstellen van fouten naarmate het geheugen op kleinere procedés wordt gemaakt. De eerste chips met ClearNand-technologie worden op 25nm geproduceerd, maar Micron wil de techniek ook toepassen op kleinere procedés, waarbij nog meer fouten optreden.
Reacties (25)
Het klinkt heel logisch dat dit ook voor flashgeheugen komt. Het lijkt me wel dat ze evengoed hun best gaan doen om fouten te voorkomen?
En wanneer zijn deze 'fouten' eigenlijk merkbaar? Is het in praktijk merkbaar wanneer je bijvoorbeeld problemen hebt met een Kingston CF kaart met Micron flash chips?
En wanneer zijn deze 'fouten' eigenlijk merkbaar? Is het in praktijk merkbaar wanneer je bijvoorbeeld problemen hebt met een Kingston CF kaart met Micron flash chips?
[Reactie gewijzigd door Red-Front op 2 december 2010 14:52]
Ik vraag mij ook af hoe ik fouten in mijn flashgeheugen ervaar. Uberhaupt heb ik nooit echt begrepen waarom een server liever ECC slikt in plaats van normaal RAM.
Geheugen kan spontaan vanished waarde veranderen. Ecc en nu dus clearnand kunnen dat herkennen en in veel gevallen corrigeren. En tsja, een server crasht dus minder snel dankzij ecc. Of misschien nog belangrijker, werkt niet verder met een foutieve waarde.
[Reactie gewijzigd door humbug op 2 december 2010 15:15]
Het werkgeheugen wat jij nu bedoeld voor de server dat liever ECC heeft is puur om het feit dat ook in DRAM fouten kunnen voorkomen. Met ECC beperk je deze fouten waardoor de kans dat een applicatie / os faalt ook stuk kleiner is.
Maar zal het ook echt werken?? of zijn dit belooftes die niet waar kunnen worden gemaakt.
EEC bestaat al langer dan vandaag, behalve dat het hier word toegepast op MLC flash in plaats van RAM is er geen verschil.
door deze constructie verlies je overigens wel 11% (8/9) van de capaciteit, of 30% (8/11) als je de fouten ook wilt corrigeren.
zie hamming code op wikiepdia, ik vermoed dat ze dat gebruiken.
door deze constructie verlies je overigens wel 11% (8/9) van de capaciteit, of 30% (8/11) als je de fouten ook wilt corrigeren.
zie hamming code op wikiepdia, ik vermoed dat ze dat gebruiken.
[Reactie gewijzigd door Darkstone op 2 december 2010 15:07]
Hamming codes werden vroeger gebruikt, en verbruikten veel minder dan 11% van de capaciteit van het geheugen: het is voldoende veel grotere codewoorden (typisch 256 bytes data+ecc ipv 1 byte data+ecc die jij voorstelt) te gebruiken.
Het echte probleem is dat NAND vroeger vrij consistent maximaal 1 fout per pagina (van 2048 en een beetje bytes had, maar dat vanwege multilevel (eerst 2 bit/cel, tegenwoordig al 3) en het kleiner worden van de geheugencellen het aantal falende cellen bij iedere generatie (bv. van 50nm naar 34nm naar 25nm) toeneemt.
Als er meer falende cellen zijn moet ook de foutcorrectie telkens aangepast worden (complexere algorithmes zijn duurder te implementeren, maar noodzakelijk om bij hoge BER het geheugen optimaal te benutten): tegenwoordig wordt meestal een BCH code gebruikt ipv hamming (dat alleen efficient is voor lage bit error rates) en ik heb al aankonigingen gezien van controllers die LDPC codes gebruiken.
Dit betekent dan ook dat het ontwerp van het toestel (gsm, mp3 speler, ...) dat het flash geheugen gebruikt telkens aangepast zou moeten worden aan de specifieke flash generatie (en evt zelfs aan de fabrikant van waar de chips komen)...
Daarom dat de Flash fabrikanten (micron is zeker niet de enige en ik denk ook niet de eerste) een ECC die in dezelfde verpakking als de flash dies steken zodat het geheel (flash+ecc) wel van een generatie op de volgende (en potentieel van een leverancier op de andere) compatibel gemaakt kan worden, en bv. een telefoon die zulke flash chips gebruikt niet aangepast moet worden om met goedkopere chips van de volgende generatie te kunnen werken.
Het echte probleem is dat NAND vroeger vrij consistent maximaal 1 fout per pagina (van 2048 en een beetje bytes had, maar dat vanwege multilevel (eerst 2 bit/cel, tegenwoordig al 3) en het kleiner worden van de geheugencellen het aantal falende cellen bij iedere generatie (bv. van 50nm naar 34nm naar 25nm) toeneemt.
Als er meer falende cellen zijn moet ook de foutcorrectie telkens aangepast worden (complexere algorithmes zijn duurder te implementeren, maar noodzakelijk om bij hoge BER het geheugen optimaal te benutten): tegenwoordig wordt meestal een BCH code gebruikt ipv hamming (dat alleen efficient is voor lage bit error rates) en ik heb al aankonigingen gezien van controllers die LDPC codes gebruiken.
Dit betekent dan ook dat het ontwerp van het toestel (gsm, mp3 speler, ...) dat het flash geheugen gebruikt telkens aangepast zou moeten worden aan de specifieke flash generatie (en evt zelfs aan de fabrikant van waar de chips komen)...
Daarom dat de Flash fabrikanten (micron is zeker niet de enige en ik denk ook niet de eerste) een ECC die in dezelfde verpakking als de flash dies steken zodat het geheel (flash+ecc) wel van een generatie op de volgende (en potentieel van een leverancier op de andere) compatibel gemaakt kan worden, en bv. een telefoon die zulke flash chips gebruikt niet aangepast moet worden om met goedkopere chips van de volgende generatie te kunnen werken.
Met ECC introduceer je extra complexiteit en extra kans op fouten. De parity-bit zelf kan ook fout zijn. CRC lijkt mij een betere keus.
Het lijkt mij daarom beter om de betrouwbaarheid van het proces te verbeteren (je hebt daar 10% extra chip oppervlak voor ter beschikking , ook nog eens...).
ECC in het flash geheugen lijkt mij daarom echt een lapmiddel.
Verder denk ik dat fout correctie beter in de geheugen controller plaats kan vinden omdat de ontwerper dan zelf meer keus heeft qua foutcorrectie type.
Het lijkt mij daarom beter om de betrouwbaarheid van het proces te verbeteren (je hebt daar 10% extra chip oppervlak voor ter beschikking , ook nog eens...).
ECC in het flash geheugen lijkt mij daarom echt een lapmiddel.
Verder denk ik dat fout correctie beter in de geheugen controller plaats kan vinden omdat de ontwerper dan zelf meer keus heeft qua foutcorrectie type.
ECC dient juist voor het verbeteren van fouten 
en alle gebruikte algorithmes van de simpelste hamming code tot de efficientste codes zoals LDPC (of eventueel turbo codes, maar daar heb ik nergens aanwijzingen van gezien dat controllerfabrikanten daarmee bezig zouden zijn) houden er wel degelijk rekening mee dat er ook fouten in de extra informatie voor foutcorrectie kan zitten.
Het gebruik van een parity bit is trouwens geen echte ECC omdat daarmee fouten alleen maar gedetecteerd maar niet verbeterd kunnen worden. CRC is voor zover ik weet ook alleen maar bedoeld voor foutdetectie en niet voor correctie.
En zoals ik in mijn vorige post zei: voor de huidige flashchips (<30nm) en zeker voor de volgende generatie (rond of net onder de 20nm) heeft ieder soort chip (ander generatie, andere fabrikant) zijn eigen type foutcorrectie nodig. Als ECC in de controller zit (zoals nu bij ongeveer al het nand flashgeheugen het geval is) moet de controller telkens vervangen worden als een fabrikant nand chips van een andere leverancier (of recentere chips) wil gebruiken ipv alleen maar een ander chipje met dezelfde interface op zijn bord te solderen.
PS. dat lapmiddel wordt al zeer lang gebruikt zowel voor NAND flash (ooit werden hiervoor hamming codes gebruikt zoals darkstone vermoedde) en in alle harddisks (maar daar merk je niet zoveel van omdat harddisks meestal niet los van hun controller te krijgen zijn)
en alle gebruikte algorithmes van de simpelste hamming code tot de efficientste codes zoals LDPC (of eventueel turbo codes, maar daar heb ik nergens aanwijzingen van gezien dat controllerfabrikanten daarmee bezig zouden zijn) houden er wel degelijk rekening mee dat er ook fouten in de extra informatie voor foutcorrectie kan zitten.Het gebruik van een parity bit is trouwens geen echte ECC omdat daarmee fouten alleen maar gedetecteerd maar niet verbeterd kunnen worden. CRC is voor zover ik weet ook alleen maar bedoeld voor foutdetectie en niet voor correctie.
En zoals ik in mijn vorige post zei: voor de huidige flashchips (<30nm) en zeker voor de volgende generatie (rond of net onder de 20nm) heeft ieder soort chip (ander generatie, andere fabrikant) zijn eigen type foutcorrectie nodig. Als ECC in de controller zit (zoals nu bij ongeveer al het nand flashgeheugen het geval is) moet de controller telkens vervangen worden als een fabrikant nand chips van een andere leverancier (of recentere chips) wil gebruiken ipv alleen maar een ander chipje met dezelfde interface op zijn bord te solderen.
PS. dat lapmiddel wordt al zeer lang gebruikt zowel voor NAND flash (ooit werden hiervoor hamming codes gebruikt zoals darkstone vermoedde) en in alle harddisks (maar daar merk je niet zoveel van omdat harddisks meestal niet los van hun controller te krijgen zijn)
[Reactie gewijzigd door ls470 op 3 december 2010 20:02]
- Tweedimensionaal CRC kan ook voor foutcorrectie gebruikt worden.
- Zoals je bij een opslagmedium als CD en DVD ziet wordt een groot deel van de foutcorrectie in het opslagformaat bepaald en dus door de software (bijvoorbeeld in firmware en brandsoftware) geregeld. Dit kan dus afhankelijk van het type data dat je wilt opslaan gekozen worden.
- Zoals je bij een opslagmedium als CD en DVD ziet wordt een groot deel van de foutcorrectie in het opslagformaat bepaald en dus door de software (bijvoorbeeld in firmware en brandsoftware) geregeld. Dit kan dus afhankelijk van het type data dat je wilt opslaan gekozen worden.
[Reactie gewijzigd door E_E_F op 5 december 2010 15:26]
Waarom zou het niet werken? Foutcorrectiecodes bestaan al vele jaren en zijn erg succesvol inzetbaar.
Kijk naar de CD-technologie. Je kan behoorlijk veel krassen op een schijfje hebben voordat die niet meer leesbaar zijn. En DVD en Blu-ray claimen nog betere foutcorrectie.
Dit is dan ook de toekomst foor Flash. Men kan de cellen veel kleiner maken en nog meer niveaus laten opslaan, maar dan komt de uitgelezen waarde vaak niet overeen met de oorspronkelijk geschreven waarde. Goede foutcorrectiecodes kunnen echter met extra informatiebits de originele data achterhalen, en in totaal kan de datadichtheid aanzienlijk stijgen.
Hetzelfde vindt ook plaats bij communicatie. Wat je ontvangt is het signaal plus ruis, en via foutcorrectiemethodes haalt men het originele signaal eruit. Hogere datarates vergen steeds betere foutcorrectie. Voor meer info zoek eens naar Viterbi turbo decoders.
Kijk naar de CD-technologie. Je kan behoorlijk veel krassen op een schijfje hebben voordat die niet meer leesbaar zijn. En DVD en Blu-ray claimen nog betere foutcorrectie.
Dit is dan ook de toekomst foor Flash. Men kan de cellen veel kleiner maken en nog meer niveaus laten opslaan, maar dan komt de uitgelezen waarde vaak niet overeen met de oorspronkelijk geschreven waarde. Goede foutcorrectiecodes kunnen echter met extra informatiebits de originele data achterhalen, en in totaal kan de datadichtheid aanzienlijk stijgen.
Hetzelfde vindt ook plaats bij communicatie. Wat je ontvangt is het signaal plus ruis, en via foutcorrectiemethodes haalt men het originele signaal eruit. Hogere datarates vergen steeds betere foutcorrectie. Voor meer info zoek eens naar Viterbi turbo decoders.
[Reactie gewijzigd door c0d1f1ed op 2 december 2010 15:11]
"Hogere datarates vergen steeds betere foutcorrectie." Waarom?
Snellere sensors, verwerkings circuits en (de-)compressie technieken lijken me veel meer van belang.
Snellere sensors, verwerkings circuits en (de-)compressie technieken lijken me veel meer van belang.
[Reactie gewijzigd door E_E_F op 3 december 2010 10:21]
volgens anandtech word de error rate groter als het productieprocess kleiner word, wellicht is dat de reden om over te gaan op EEC flash.
Misschien moeten ze eerst zorgen dat ze het productie proces onder de knie hebben voordat ze er productie chips mee te gaan maken. Dan hoeven ze dit soort trucs niet te implementeren.
dit ziet er niet uit als truuk, maar noodzaak.
volgens hetzelfde artikel bevat de intel ssd gen 3 deze nieuwe RAM technologie, het vordeel is dat je dan geen EEC in je chip hoeft te programmeren.
volgens hetzelfde artikel bevat de intel ssd gen 3 deze nieuwe RAM technologie, het vordeel is dat je dan geen EEC in je chip hoeft te programmeren.
Zo eenvoudig ligt het niet hoor. Bij harde schijven heb je een gelijkaardig probleem. Er zit tegenwoordig zoveel data op een klein oppervlak, dat het onmogelijk is om deze data nog helemaal goed uit te lezen. Maar door gebruik van methodes om verkeerd gelezen bitjes te recupereren, slaagt men erin om toch gebruik te maken van schijven met zo een hoge datadichtheid.
Flash geheugen slijt, een geheugen cel kan een beperkt aantal write cycles aan, en gaat op een gegeven moment stuk. Dus los van het feit of het al dan niet 100% goed geproduceerd is krijg je op een gegeven moment data corruptie, met ecc eroverheen zal het langer duren voordat er zodanig veel cellen zijn overleden dat je data echt verloren is.
Wat uiteindelijk uitmaakt is dat het eindresultaat zo goedkoop mogelijk, maar toch betrouwbaar is...
MLC NAND flash geheugen (toch zeker onder de 70nm) kan eingenlijk niet 100.00000% betrouwbaar gemaakt worden en heeft altijd ECC nodig. Door het kleiner maken van het geheugen wordt het er alleen maar erger op (een verlies van 1 elektron per maand betekent al dat de cel faalt) en voor veel problemen is er geen enkele oplossing bekend. De keuze is dan helaas geheugen verkopen dat een hele trucendoos (redundancy; ECC, blad block management, ...) nodig heeft om betrouwbaar te werken of veel (10x of 100x) duurder of zelfs helmaal geen geheugen verkopen
MLC NAND flash geheugen (toch zeker onder de 70nm) kan eingenlijk niet 100.00000% betrouwbaar gemaakt worden en heeft altijd ECC nodig. Door het kleiner maken van het geheugen wordt het er alleen maar erger op (een verlies van 1 elektron per maand betekent al dat de cel faalt) en voor veel problemen is er geen enkele oplossing bekend. De keuze is dan helaas geheugen verkopen dat een hele trucendoos (redundancy; ECC, blad block management, ...) nodig heeft om betrouwbaar te werken of veel (10x of 100x) duurder of zelfs helmaal geen geheugen verkopen
Als je grotere hoeveelheden data op wilt slaan heb je meer transistors nodig. Het is gewoon niet economisch haalbaar om elke chip met één niet-helemaal-lekker-werkende transistor botweg in de vuilnisbak te kieperen.
De vergelijking klopt niet helemaal, maar als ik even wat bochten af mag snijden dan kun je het vergelijken met CPUs (of GPUs wat dat betreft). Ook daar zitten regelmatig foutjes in, waarna een core of (een deel van) de cache wordt uitgeschakeld zodat je de chip alsnog kunt verkopen. Kennelijk is het voor geheugenchips goedkoper om de (zeldzame) "slechte" transistors te negeren (en foutcorrectie toe te passen) dan extra blokken geheugen te produceren en enkele blokken uit te schakelen. Zeker bij Flash (wat in de loop der tijd slijt door de hoge programmeerspanningen) lijkt me dat een prima oplossing. Zeker omdat het hebben van foutcorrectie je meteen ook in staat stelt om te detecteren wanneer de slijtage zo erg wordt dat een sector (of de hele chip) beter niet meer gebruikt kan worden.
De vergelijking klopt niet helemaal, maar als ik even wat bochten af mag snijden dan kun je het vergelijken met CPUs (of GPUs wat dat betreft). Ook daar zitten regelmatig foutjes in, waarna een core of (een deel van) de cache wordt uitgeschakeld zodat je de chip alsnog kunt verkopen. Kennelijk is het voor geheugenchips goedkoper om de (zeldzame) "slechte" transistors te negeren (en foutcorrectie toe te passen) dan extra blokken geheugen te produceren en enkele blokken uit te schakelen. Zeker bij Flash (wat in de loop der tijd slijt door de hoge programmeerspanningen) lijkt me dat een prima oplossing. Zeker omdat het hebben van foutcorrectie je meteen ook in staat stelt om te detecteren wanneer de slijtage zo erg wordt dat een sector (of de hele chip) beter niet meer gebruikt kan worden.
Beide technieken zijn noodzakelijk: cellen (transistors) of blokken die tijdens het testen als slecht gezien worden kunnen vervangen worden (redundancy) of simpelweg als slecht aangeduid (wie een nand datasheet leest zal daarin zien dat de fabrikant aangeeft dat het normaal is dat een aantal blokken/paginas vanaf het begin al slecht zijn). Als er maar één foutje inzit kan er ook op de foutcorrectie gerekend worden zoals je voorstelt natuurlijk.
Er zullen echter altijd fouten zijn die niet door het testen gedetecteerd worden: het is niet praktisch iedere flash chip 10 jaar lang te testen om te zien of de informatie behouden blijft, en voor sommige lekmechanismen (abnormale SILC, die veroorzaakt wordt door trap to trap tunneling, en dus amper temperatuursafhankelijk is) is het niet mogelijk effectieve versnelde tests uit te voeren.
Ook bestaan er defecten die willekeurig aan en uit schakelen, zodat de kans vrij groot is dat een cel die zijn lading verliest alle volgende keren dat hij geschreven/gebruikt wordt wel zal blijven werken. Dan zou het niet efficient zijn om die cel definitief als slecht aan te duiden.
Er zullen echter altijd fouten zijn die niet door het testen gedetecteerd worden: het is niet praktisch iedere flash chip 10 jaar lang te testen om te zien of de informatie behouden blijft, en voor sommige lekmechanismen (abnormale SILC, die veroorzaakt wordt door trap to trap tunneling, en dus amper temperatuursafhankelijk is) is het niet mogelijk effectieve versnelde tests uit te voeren.
Ook bestaan er defecten die willekeurig aan en uit schakelen, zodat de kans vrij groot is dat een cel die zijn lading verliest alle volgende keren dat hij geschreven/gebruikt wordt wel zal blijven werken. Dan zou het niet efficient zijn om die cel definitief als slecht aan te duiden.
In combinatie met filesystems als ZFS of Btrfs zou ik persoonlijk liever een onderliggende storage zonder foutcorrectiecodes willen hebben (rotte data wordt dan toch wel opgemerkt door de self-healing/checksum code van de storage pool manager, en anders zou je dus dubbel werk doen)... maar voor 'klassieke' bestandssystemen zou dit wel een uitkomst zijn.
[Reactie gewijzigd door Sfynx op 2 december 2010 15:45]
Foutencorrect wordt continu toegepast bij het opslaan/verzenden van data. Er kan genoeg gebeuren waardoor een bit plots wisselt. ECC is niet altijd noodzakelijk, vooral bij de gemiddelde flashgeheugen toepassingen.
Flashgeheugen is door zijn snelheid tegenwoordig een zeer groot aandeel van dataopslag, maar vaak ook van korte levensduur (vandaar dat SSD's veel minder R/W cycles aankunnen). Gelukkig worden er al technieken onderzocht die deze zal vervangen: MRAM (snel, lange levensduur, kost meer vermogen), PRAM (stabiel, lange levensduur, ook snel) en RRAM.
Ik vrees dat dit meer een stunt is van Micron om een erg aantrekkelijk 'error-correcting' toe te voegen aan hun product. Mijn i7 processor heeft genoeg cycles over - mijn harde schijven en geheugen zijn momenteel de bottleneck!
Flashgeheugen is door zijn snelheid tegenwoordig een zeer groot aandeel van dataopslag, maar vaak ook van korte levensduur (vandaar dat SSD's veel minder R/W cycles aankunnen). Gelukkig worden er al technieken onderzocht die deze zal vervangen: MRAM (snel, lange levensduur, kost meer vermogen), PRAM (stabiel, lange levensduur, ook snel) en RRAM.
Ik vrees dat dit meer een stunt is van Micron om een erg aantrekkelijk 'error-correcting' toe te voegen aan hun product. Mijn i7 processor heeft genoeg cycles over - mijn harde schijven en geheugen zijn momenteel de bottleneck!
''Ik vrees dat dit meer een stunt is van Micron om een erg aantrekkelijk 'error-correcting' toe te voegen aan hun product. Mijn i7 processor heeft genoeg cycles over - mijn harde schijven en geheugen zijn momenteel de bottleneck!''
Maarja als je dit zou implementeren in een telefoon of media speler. Meer cycles is meer stroomverbruik. En ik denk dat daarom ECC op flashgeheugen toch wel interesant is.
Edit: Typo
Maarja als je dit zou implementeren in een telefoon of media speler. Meer cycles is meer stroomverbruik. En ik denk dat daarom ECC op flashgeheugen toch wel interesant is.
Edit: Typo
[Reactie gewijzigd door Wh0lve op 2 december 2010 19:32]
Wanneer gaat tweakers een keer een artikel wijden aan flash?
De verschillen, commercial vs industrial, slc, mlc, tlc etc. Tegenwoordig zie je door de bomen het Bosch niet meer. Wat ik zie is dat mijn sdhc kaarten steeds eerder corrupt geraken bij langdurige read stress. (muziekant)
De verschillen, commercial vs industrial, slc, mlc, tlc etc. Tegenwoordig zie je door de bomen het Bosch niet meer. Wat ik zie is dat mijn sdhc kaarten steeds eerder corrupt geraken bij langdurige read stress. (muziekant)
Opmerkelijk, al de reaacties hier. Misschien had het rtikel beter kunnen vermelden hoe Flash ECC nu werkt. Alle flash systemen hebben namelijk ECC Alleen, nu heb je altijd een controller die een paar flash chips aanstuurt. De ECC zit nu in de controller, niet in de flash chips zelf.
Er zijn een paar voordelen aan het verplaatsen van de ECC naar de flash chips. Je kunt de fout een nanoseconde eerder vinden en corrigeren, en de controller krijgt het minder druk waardoor je meer flash chips met 1 controller kunt aansturen.
Er zijn een paar voordelen aan het verplaatsen van de ECC naar de flash chips. Je kunt de fout een nanoseconde eerder vinden en corrigeren, en de controller krijgt het minder druk waardoor je meer flash chips met 1 controller kunt aansturen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
