Hallo, Ich schreibe gerade meine Bachelorarbeit über Dateisysteme im embedded Bereich und darin geht es unter Anderem auch um die Unterschiede zwischen NAND und NOR Flashbausteinen. Nun ist NAND Flash ja dafür bekannt, eine er eine relativ hohe Fehlerhäufigkeit zu besitzen, deshalb werden die Bausteine häufig auch mit Hardware-ECC verkauft oder ECC wird zumindest softwareseitig im Treiber vom Dateisystem implementiert. Allerdings habe ich während meiner Suche kein einziges Dateisystem gefunden was ECC für NOR Flash implementiert und nur einen Hersteller (ISSI) gefunden der Bausteine mit Hardware-ECC anbietet, wobei diese auch noch recht neu sind (Release erst dieses Quartal). Meine Frage ist nun ob irgendjemand tatsächliche Daten über die Unterschiede in der Bit-Error-Rate zwischen NAND und NOR Flashbausteinen hat oder weiß wo ich sie finden kann. Es muss ja einen Grund geben warum sich alle auf NOR Flash verlassen. Vor allem würde mich dann interessieren ob die Fehlerhäufigkeit von einem NAND Flash mit ECC nicht vielleicht sogar niedriger ist als von einem NOR Flash ohne ECC. Ich habe an alle großen Chiphersteller bereits Anfragen geschickt aber seit Wochen keine Antwort bekommen. Auch habe ich deren Webseiten nach Papers durchsucht aber auch dort keine Zahlen gefunden immer nur die Aussage, dass sie zuverlässiger sind. Vielen Dank im Voraus.
Georg schrieb: > Vor allem würde mich dann interessieren ob die Fehlerhäufigkeit von > einem NAND Flash mit ECC nicht vielleicht sogar niedriger ist als von > einem NOR Flash ohne ECC. ECC dient nicht unbedingt dazu, die Fehlerrate zu verringern, sondern um Fehler überhaupt zu erkennen, damit z.B. die Software nicht Amok läuft und der Roboter jemanden zu tode prügelt.
Johnny B. schrieb: > ECC dient nicht unbedingt dazu, die Fehlerrate zu verringern, sondern um > Fehler überhaupt zu erkennen, damit z.B. die Software nicht Amok läuft > und der Roboter jemanden zu tode prügelt. Hallo, was könnte denn ECC sein, etwa ein Error Recognition Code ? Gruß, Michael
Der wesentlich Unterschied zwischen NAND und NOR ist, dass man NAND in großen Blöcken ansprechen muss, währen man bei NOR einzelne Bytes lesen kann. Das bedeutet, dass das Flash, in dem ausführbarer Code in Mikrocontrollern gespeichert wird, NOR sein muss. Der selbe Transistor hat ungefähr die selbe Fehlerhäufigkeit, egal, ob er in NAND- oder NOR-Flash benutzt wird. Aber in Mikrocontrollern will man zuverlässigen Speicher ohne ECC-Aufwand und macht deshalb die Transistoren groß und robust, während es sich bei Massenspeichern lohnt, möglichst viele Transistoren auf den gleichen Raum zu quetschen und die daraus resultierenden Fehler mit ECC (und komplexer Software) auszubügeln.
Der wesentliche Unterschied ist, daß bei NOR die "Verkabelung" der einzelnen Speicherzellen so umständlich und sperrig ist, daß man sie nicht beliebig verkleinern kann. Bei NAND geht das, also machen es die Hersteller auch. Damit bekommt man mehr Speicherkapazität auf den Chip, aber je kleiner die Speicherzellen sind, desto größer ist die Fehlerwahrscheinlichkeit. Deshalb ist bei NAND-Flash aufwendige Fehlerkorrektur nötig, damit man seine Daten hinterher noch wiedererkennt. Zu der Fehlerkorrektur gehört dann auch, daß man nur noch blockweise schreiben kann, weil zu jedem Block entprechende Prüfsummen gespeichert werden müssen. Bei NOR ist keine Fehlerkorrektur nötig, weil praktisch keine Fehler auftreten. Dateisysteme haben damit normalerweise nichts zu tun, weil die auf einer höheren Schicht ansetzen und davon ausgehen, daß sie ein zuverlässiges Speichermedium für Datenblöcke zur Verfügung haben. Für das korrekte Betüddeln des NAND-Flashs steckt dann ein eigener Prozessor im Speichermedium (USB-Stick, SD-Karte, SSD, eMMC,...).
Naja, solange man sich im Bereich von "embedded Flash" bewegt, sind sie 100k P/E Cycles fast gleich. Nachteil von NAND ist halt dass man immer nur größere Blöcke löschen kann als bei NOR. Das heißt ohne entsprechende Logik (wear Leveling) hält NAND weniger lang wenn kleine Datenblöcke geschrieben werden. Sobald es in den Bereich von SSDs geht (welche fast ausschließlich NAND in Form von MLC/TLC/QLC mit recht kleinen Fertigungsprozessen verwendenden) reden wir von P/E Cycles von ~1000-3000 Cycles. Bei einer Samsung EVO 860 mit 1TB sind es lediglich 600 TBW (Terabytes Written) garantiert. Bedeutet 600 mal voll geschrieben und das Ding ist kaputt (wir alle wissen ja dank diverser Tests dass diese angaben recht konversativ sind). Bei Konsumer ist es meist 0.3 DWPD bei Server etc. geht es auch gerne auf 3 DWPD hinaus.
Nosnibor schrieb: > Dateisysteme haben damit normalerweise nichts zu tun, weil die auf einer > höheren Schicht ansetzen und davon ausgehen, daß sie ein zuverlässiges > Speichermedium für Datenblöcke zur Verfügung haben. Das ist so nicht richtig. Dafür machen ja Dateisystem wie ZFS oder BTRFS Scrubbing, eben weil sie Speichermedien als fehlerbehaftet und unzuverlässig ansehen.
Neverever schrieb: > Dafür machen ja Dateisystem wie ZFS oder BTRFS > Scrubbing, eben weil sie Speichermedien als fehlerbehaftet und > unzuverlässig ansehen. Überdies verwenden sie auch eigene Checksums.
Georg schrieb: > Allerdings habe ich während meiner Suche kein einziges Dateisystem > gefunden was ECC für NOR Flash implementiert und nur einen Hersteller > (ISSI) gefunden der Bausteine mit Hardware-ECC anbietet, wobei diese > auch noch recht neu sind (Release erst dieses Quartal). Da war die Suche aber ziemlich oberflächlich. Auf Anhieb fallen mir dazu Cypress' S25FL128S, S25FL256S, S25FL512S ein, steht ausdrücklich auf der ersten Seite im Datenblatt. Oder Macronix MX25LM51245G. Auch bei einigen neueren STM32-Derivaten mit größerem Flash findet sich ECC. Dabei dürfte es sich wohl auch um NOR-Flash handeln?! Der Grund wurde ja schon beschrieben: In Integrationsdichte ist bei NOR der bei NAND deutlich hinterher, und die Fehlerwahrscheinlichkeit wächst mit Verkleinerung der Strukturen.
A. B. schrieb: > Der Grund wurde ja schon beschrieben: In Integrationsdichte ist bei NOR > der bei NAND deutlich hinterher, und die Fehlerwahrscheinlichkeit wächst > mit Verkleinerung der Strukturen. Und mit der Anzahl Bits pro Speicherzelle, bei NAND mittlerweile bis zu 4.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.