News ISSCC: Microns 768-Gbit-NAND-Flash erreicht 2,77 Tbit/Zoll²

[Excel]

Ich bin auch dafür, inch nicht mehr zu verwenden. Es gibt einheitliche Systeme, die man verwenden kann und sollte. Wir benutzen hier ja auch kein Unzen, obwohl es in den USA gebräuchlich ist. Die parallele Verwendung von inch und mm bringt dann die perfekte Verwirrung.

Dasselbe Chaos bei Festplatten, wo die Baugröße in Zoll angegeben wird, die Höhe aber in mm :/

 

[haha]

Bei der Logik auf den Chips geht es mindestens um die Signalverarbeitung und die Schwellwerte für die Thresholds, ggf. aber auch um eine zusätzliche Fehlerkorrektur. Das gibt es schon seid den 25nm bei NANDs und wird dort als Clear NAND bezeichnet.

Schwellwert und Threshold sind das Gleiche, nur in einer anderen Sprache.
Korrekter wäre, Schwellwerte für die Logik-Pegel, was essentiell für die Schnittstellenlogik ist.

Die Fehlerkorrektur ist nicht zur Erhöhung der Langlebigkeit da, sondern zur Verbesserung der Datenintegrität.

Der Text in deinem Link gibt leider auch nicht mehr Details preis. Er ist mehr eine typische Presseerklärung mit wiederholter Lobpreisung Microns

Ich hab ja nichts dagegen, dass in den Flash-Dies sogar zusätzliche Logik zur Verbesserung der Haltbarkeit der Flash-Zellen integriert ist. Die Frage ist aber, welche Mechanismen da nun genau wirken.

 

[Holt]

Was solls. Eine Schlagzeile sei ihnen gegönnt.

Mehr ist es ja auch nicht, die 768- Gbit NANDs sind ja weder in Produktion noch werden sie demnächst in Produktion gehen, oder stimmt diese Aussage etwa nicht mehr:

Intels und Microns 3D-NAND-Debüt soll in diesem Jahr mit 32 Lagen und 256 Gbit (MLC) beziehungsweise 384 Gbit (TLC) den Markt erreichen.

Damit ist das also Zukunftsmusik so wie von der tollen Packungsdichte von 7nm oder 10nm CPUs zu berichten.

Immerhin besser als einen Totenkopf auf den Deckel malen.

Den macht Intel wohl extra drauf damit entscheider in Unternehmen sich gegen die SSDs entscheiden, denn im Grund ist die Intel 730 eine DC S3500.

Nicht das Entwicklungsland ist entscheidend, das Marketing ist es.
Vor ein paar Jahren noch hatte niemand einen Fernseher, dessen Größe in Zoll angegeben war.

Und wo liefen die ersten Fernehübertragungen? Eben in Deutschland, da wurden schon die Olypischen Spiele 1936 übertragen und es gab lange viele bedeutende Fernsehhersteller in Deutschland. Aber Flachbildschrine kammen von Anfang an nur als Importware nach Deutschland, also kauft man nicht mehr einen Fernsehr mut 66cm Bilddiagonale, sondern einen mit 26", wobei das eine damals ein ganz großer war und das heute ein kleiner ist.

Und noch früher, als IT noch gleichbedeutend mit Großrechern von IBM, CDC und Co. war, wurde ALLES eingedeutscht. Die (d)englischen Begriffe kamen erst mit der Schlampigkeit der PC-Ära.

Das ist wohl eher der allgemeine Zeitgeist, aber sogar englisch klingenden Worte erschafft, die außerhalb Deutschlands keiner kennt, wie z.B. Handy.

Schon an der Angabe "Gbit" in der Überschrift ist in Bezug auf SI-Einheiten alles falsch, es müßte schließlich "Gib" heißen.

Gibibit wären zwar die korrekt Angabe, sind aber nicht die übliche Angabe dafür. Hier am Beispiel eines alten Micron NANDs:

Das 32Gbit NAND hat 4096 Blöcke.
Ein Block hat 256 Pages.
Eine Page hat 4096 Byte + 224 Bytes extra die nicht eingerechnet werden, da sie nicht für Nutz- sondern für Verwaltungsdaten wie die ECC gedacht sind, bei den HDDs rechnet man die Sync- und ECC Bereiche ja auch nicht mit ein.
Also 4096*256*4096*8 / 1024^3 = 32.

Da Endkunden aber keine NAND Chips kaufen sondern eben Endprodukte wie SSDs ist das egal und wenn man ganz genau sein will, muss man auch zuerst einmal alle RAM Riegel umlabeln, da sind auch nie 4, 8 oder 16GB drin, sondern immer GiB und die kauft der Kunde direkt.

Aber letztlich sind die Angaben wie die Datendichte oder die Diesize eines der NANDs für den Kunden nicht wirklich relevant, so wie die nm der Fertigungsstukturen für ihn Grunde keine andere Rolle spielen außer als Hinweis auf die Eigenschaften und auf die Aktualität des Produktes zu dienen. Nur während keine Fertigungsstrukturen bei CPUs eher gute Eigenschaften wie hohe Effizienz und eine bessere Performance als bei älteren Modellen versprechend, deuten große Die- und vor allem Pagesizesize eher auf schlechtere Performance bei den Produkten hin.

96MB Blocksize deutet nämlich auf eine Pagesize von 32 bis 64k hin, das wären dann 3072 oder 1536 Pages pro Block (das liegt im Rahmen des übliche) und dann kommt man beim 4k Schreiben eine WA von mindestens 8 bzw. 16, wenn der Controller die Daten nicht puffert und zusammenfasst.

MichaG, da ist noch ein Fehler:

Blöcke von 96 MByte genutzt werden, die sich nicht partiell löschen beziehungsweise beschreiben lassen.

Man kann Blöcke nicht partiell Löschen ist korret, aber das Beschreiben und auslesen geht Pageweise, das ist also falsch, streiche also beziehungsweise beschreiben, außer Micron hat da auch was geändert, aber das kann ich mir nicht vorstellen, das wäre komplett unsinnig und würde die Performance bei kleinen Schreibzugriffen total in den Keller gehen und die WA enorm steigen lassen oder einen aufwendigen Controller erfordern um genau das zu verhindern.

 

[WinnieW2]

Aber ich kann gerne noch zusätzlich Gbit/mm² hinzufügen. <- Erledigt!

Vielen Dank dafür.
Was die Maßangaben betrifft. Langsam aber sicher wechseln zumindest die wissenschaftlichen Einrichtungen in den USA hin zum metrischen System. Die NASA z.B. hat als Organsation intern auf metrische Angaben umgestellt; auch wenn Inch bei den Normalbürgern noch weit verbreitet ist.

 

[MichaG]

@Holt:

The Micron architecture may have at least one Achilles heel. It currently uses relatively large 96 MByte blocks and does not enable a partial block write or erase operation.

Quelle: http://www.eetimes.com/document.asp?doc_id=1328874&page_number=1

 

[Wattwanderer]

Mir fällt es schwer, über die Maßangabenwirrwarr zu klagen.

Mit SSD haben wir ja erlebt wie Latenzen von ms nach iops gewandert sind ohne dass es einen Aufrschrei gab obwohl die direkte Vergleichbarkeit zwischen HDD und SSD dabei auf der Strecke blieb.

Auch rechnet wohl keiner wirklich Karat in Gramm oder Fass in Liter um?

Also, so lange vergleichbare Eckdaten in einheitlichen Maßen angegeben werden habe ich keine Probleme mich daran zu gewöhnen.

 

[Holt]

MichaG, das wäre dann je deren 3D NAND neu, denn normalerweise sind Pages die kleinste Einheit die man lesen und beschreiben kann, Blöcke die kleinste Einheite die man löschen kann. Daher auch der Name Flash, weil beim Löschen wie ein Blitz alle Daten in einem Block gelöscht werden. Wenn nun auch das Schreiben bei dem NAND nur noch blockweise geht und die Blöcke dann noch 96MB große sind, bisher sind, wäre eine DRAM Cache und dazu eine ausreichend dimensionierte Power-Fail-Protection eigentlich für jede SSD mit dem NAND absolute Pflicht.

Wattwanderer, eben, solange alle die gleichen Einheiten nutzen ist es gerade bei solch abstrakten Dingen wie der Datendichte total egal welche Einheit das ist, die kann man doch nie nachmessen. Ob die Rohölpreise nun in Barrel oder Tonnen angegeben werden, ist doch auch egal, mit dem was Du an der Tanke zahlen musst, hat das sowieso nur wenig zu tun und an der Zapfsäule wird die Abgabemenge in Liter gezählt, genau wie es auf der Preistafel steht und wie es auch der Bordcomputer Deines Autos anzeigen sollte. Wo ist also das Problem, wenn die Größenangabe für das Display des Boardcomputers nun 7" ist statt 17,8cm? Nachmessen tut das doch keiner und das ein 8" Display größer ist, sollte auch jedem klar sein.

 

[Hallo32]

@Holt

Warum so kompliziert und teuer? Die einfache Lösung ist doch SLC Cache in entsprechender Größe.

 

[smalM]

Und wo liefen die ersten Fernehübertragungen? Eben in Deutschland, da wurden schon die Olypischen Spiele 1936 übertragen und es gab lange viele bedeutende Fernsehhersteller in Deutschland. Aber Flachbildschrine kammen von Anfang an nur als Importware nach Deutschland, also kauft man nicht mehr einen Fernsehr mut 66cm Bilddiagonale, sondern einen mit 26", wobei das eine damals ein ganz großer war und das heute ein kleiner ist.

Nein, die Zollangaben entsprangen eher dem Bedürfnis, die Größe der Bilddiagonale von Flachbildschirmen (tatsächliche Bildgröße) von der Angabe bei Bildröhren (Außenabmessungen des Glaskolbens) abzugrenzen.

Fernsehen mag zwar eine deutsche Erfindung sein, ein Fersehsender wurde aber nur eingerichtet, weil die BBC ein Fernsehprogramm angekündigt hatte. Die Fernseher standen dabei in öffentlichen Vorführräumen. Ein Fernseher für Privathaushalte wurde zwar bis 39 entwickelt, ging aber wegen des Kriegsausbruchs nie in die Produktion.

Das ist wohl eher der allgemeine Zeitgeist, aber sogar englisch klingenden Worte erschafft, die außerhalb Deutschlands keiner kennt, wie z.B. Handy.

Das ist das eine. Das andere ist, daß englische Bezeichnungen schon vorhandene deutsche Bezeichnungen verdrängten. Die Leute im PC-Bereich haben die Begriffe einfach aus den amerikanischen PC-Publikationen übernommen, die Unternehmen war ja unbekanntes Terain, die dort benutzten deutschen Fachbegriffe unbekannt.
Ein schönes Beispiel ist die Fehlübersetzung "editieren" aus "to edit". Der deutsche Begriff, "edieren", ist außerhalb von Verlagen vom denglischen Wort völlig verdrängt worden.

Gibibit wären zwar die korrekt Angabe, sind aber nicht die übliche Angabe dafür.

Nur weil ganz viele etwas falsch benutzen wird es dadurch nicht richtiger.
Aber die korrekte Nutzung von GB und GiB würde uns so Forenanfragen "wieso hat meine 1TB-Festplatte nur 931GB?" ersparen. Und es entfiele auch die Antwort, das komme durch die Formatierung.
Es gibt übrigens ein paar wenige Seiten, die sehr konsequent die Angaben von Binär- und Dezimalpräfixen auseinanderhalten. Es ist also machbar!

Wieso man sich nämlich im Jahre 2016 immer noch an Notbehelfen aus der 8-bit-CPU-Zeit orientiert, ist mir völlig schleierhaft. Schließlich sind wir nicht mehr darauf angewiesen, daß eine "KB"-Angabe nur ein Laden des höherwertigen Bytes und zweimal Shift benötigt. Ein bißchen mehr CPU-Leistung steht ja inzwischen zur Verfügung und die größtmögliche Angabe ist auch nicht mehr "64KB"...

Warum so kompliziert und teuer? Die einfache Lösung ist doch SLC Cache in entsprechender Größe.

Ein (planarer) SLC-Cache würde viel Platz auf dem Die beanspruchen (wegen der hohen Beanspruchung als Cache werden große Zellen benötigt), das erhöht die Kosten deutlich. Und die inzwischen übliche pseudo-SLC-Lösung unterliegt denselben Bedingungen bzgl. der Blockgröße wie der ganze Rest des NANDs.
Da ist ein dedizierter RAM-Baustein wohl weder komplizierter noch teurer.

 

[Holt]

Hallo32, aber dann müssten immer noch 32MB am Stück geschrieben werden, denn auch wenn nur ein Bit pro Zelle geschrieben wird, so wird gewöhnlich doch ein normaler NAND Bereich genommen, der hat dann eben nur ein Drittel der Kapazität, aber 32MB wäre immer noch gewaltig viel, vor allem im Vergleich zu den normale 8k oder 16k pro Page. Auch wenn das Schreiben nur eines Bit deutlich schneller als bei alle 3 Bits geht, so dauert das für 32MB immer noch eine Weile, man kann dann nicht viele IOPS erzielen, wenn man immer gleich alle Daten dort ablegt, außerdem ist der schnell voll, wenn man von den 32MB nur 4k wirklich mit Daten belegt.

Außerdem:

Dafür könnten Daten aber nur mit 44 statt 53 MByte/s geschrieben werden.

Das wären dann über 2s um 96MB in den normalen NAND Bereich zu schreiben, eine sehr lange Zeit für einen Vorgang der dann meist irgenwann im Idle erfolgt und wo man nur hoffen kann, dass in der Zeit die Spannung nocht abfällt? Klingt nicht wirklich verlockend.

Eigentlich kann das nur ein Fehler sein, aber das bei dem NAND etwas anderes ist, zeigt die Leserate von 800 MByte/s statt der 178 MByte/s bei Samsungs VNAND (jeweils pro Die). Trotzdem verstehe ich nicht, was da genau hinter stecken sollte, wenn es wirklich so korrekt wäre und da nicht jemand einen Fehler gemacht und vergessen hat, dass das Schreiben und Lesen bei NAND eben normalerweise pageweise passiert.

Ergänzung (9. Februar 2016)

Nur weil ganz viele etwas falsch benutzen wird es dadurch nicht richtiger.
Aber die korrekte Nutzung von GB und GiB würde uns so Forenanfragen "wieso hat meine 1TB-Festplatte nur 931GB?" ersparen.

Das stimmt zwar, aber wie gesagt ist das ein Detail mit dem kein normaler Nutzer je direkt in Berühung kommt, denn wir kaufen ja keine NAND Chips, sondern fertige Produkte und da wird dann sowieso immer ein Teil der Kapazität für andere Aufgaben gebraucht und steht nicht für Nutzdaten zur Verfügung und damit spielt nur das GB und GiB Problem eine Rolle, nicht die Frage ob der Chip darin nun 256Gigabit oder Gibibit hat, die SSD in der er steckt hat dann sowieso 256GiB NAND und 256GB (oder weniger) Nutzkapazität.

Ein (planarer) SLC-Cache würde viel Platz auf dem Die beanspruchen (wegen der hohen Beanspruchung als Cache werden große Zellen benötigt)

Die Pseudo-SLC Cache alles bisherige TLC NAND SSDs sind mit den ganz normalen NAND Zellen realisiert, die werden eben einfach nur mit einem Bit beschrieben, das ist weder spezielles SLC NAND auf den Chips noch hat es andere Sturkturbreiten. Ein Extra SLC NAND Bereich wäre da totaler Blödsinn, da die Zellen bei Nutzung mit immer nur einem Bit sowieso viel länger halten, aber beim 3D NANDs wo Micron schon die Steuerlogik auf einer extra Schicht untergebracht hat, wäre das natürlich eher denkbar als auf einem Chip wo diese neben dem Bereich für die Zellen liegt und dort wo die Speicherzellen sind auch "gestapelte" NAND Zellen sind.

 

[Hallo32]

Da ist ein dedizierter RAM-Baustein wohl weder komplizierter noch teurer.

Der RAM ist selbst ist nicht das Problem, aber falls sich wirklich solche Mengen an Benutzerdaten im Ram befinden, sollten die SSDs auch eine Power Loss Funktion haben, die die Daten in den Flash schreiben kann.

Die dafür notwendige Energie dürfte nicht gerade gering sein und muss auf der SSD vorgehalten werden. Ob die "Kondensatorgräber" sich dafür noch eignen werden? Des Weiteren dürfte es auf M.2 SSDs vom Platz ein wenig eng werden, wenn ich mir die aktuellen Realisierungen anschaue.

Ergänzung (10. Februar 2016)

@Holt

Die Frage bei den Flash dürfte auch sein, welchen Kunden die Zielgruppe einer möglichen SSD sind.

Für die System SSD scheint sich der Flash ohne Cache in der aktuellen Form nicht zu eignen. Ob man den SLC oder MLC wirklich als Pseudo Version realisieren muss, wäre ich mir gar nicht so sicher. Was spricht gegen einen DIE im Package der einen anderen Aufbau aufweist und als Cache verwendet wird? Bzw. evtl. einfacher zu realisieren als einzelnes Package, dann müssen die Daten aber wahrscheinlich beim "Umkopieren" noch einmal durch den Controller.

Oder die SSD wird als "preiswertes" Speichermedium mit den Schwerpunkt auf hohe Lesegeschwindigkeit und nicht so optimalen Schreibeigenschaften vertrieben, vergleichbar mit Shingled Magnetic Recording (SMR) HDDs. Dort könnte man das Caching dann evtl. auch per Software (Magican usw.) direkt vom System erledigen lassen, wenn die SSD auf €/GB optimiert wird.

 

[Holt]

Ja die Frage wofür so ein NAND dann verwendet werden dürfte, scheint wohl in diese Richtung zu gehen:

Toshibas QLC-NAND mit 4 Bit pro Zelle für Archiv-SSDs
...
Bei solchen „Archiv-SSDs“ werden Daten meist nur selten oder gar nur einmalig auf den Flash-Speicher geschrieben und stehen dann vor allem zum Abruf bereit, was nur Lesezugriffe bedeutet.

Damit hat man dann tatsächlich etwas ähnliches wie die SMR HDDs geschaffen, schreiben ist deren Stärke nicht, aber mit Caches kann man diesen Nachteil wenigstens über einige GB ausgleichen.

Die SSDs haben die HDDs in den kleinen Formfaktoren, also 1,8" und 1" ja schon vor einiger Zeit komplett abgelöst, die Enterprise Perfornance HDDs mit 15.000rpm werden gerade durch SSDs ersetzt und nun wird wohl schon zum Angriff auf die eigentlich noch recht junge Gattung der Archive HDDs wie die Seagate Archive und HGST Ha10 geblasen. Das Argument für die SSD ist dann klar die viel bessere Lesegeschwindigkeit und da versprechen ja 800 MByte/s statt der 178 MByte/s bei Samsungs aktueller Generation noch einmal einen echten Quantensprung und würde es auch erlauben die Daten einer Datei einfach hintereinanderwg in ein Die zu schreiben, statt sie wie bisher über mehrere zu verteilen um sie schnell genug lesen zu können.

Warten wir mal ab was da kommt, noch ist das ja reichlich Zukunftsmusik und die Ankündigung dient vielleicht auch dazu den Markt dafür zu sondieren, vorher soll ja nun in diesem Jahr das 3D NAND mit 32 Lagen und 256 Gbit (MLC) beziehungsweise 384 Gbit (TLC) auf den Markt kommen und das dürfte wohl wie gewohnt pageweise beschreibbar sein und die Pages dürfte weiter nur im kByte Bereich liegen, auch wenn Micron da wohl wieder traditionell eher auf größere Pagesize setzt. Intel und Micron scheinen jedenfalls bei der Forschung für 3D NANDs verschiedene Ansätze weiterverfolgt zu haben.