Micron werkt aan tlc-nand-chip van 768Gbit

Micron werkt aan een nand-geheugenchip van 768Gbit met een oppervlakte van 179,2mm². De chip heeft daarmee een hogere opslagdichtheid dan de huidige 256Gbit-chip van Samsung. Micron weet nog niet of de chip daadwerkelijk op de markt komt.

De 3d-nand-chip van Micron biedt maximale sequentiële leessnelheden van 800MB/s en schrijfsnelheden van 44MB/s. Met zijn oppervlakte van 179,2mm² en opslagcapaciteit van 768Gbit heeft de chip een opslagdichtheid van 4,29Gbit/mm². Het gaat om een 3d-chip waarbij de controller onder de flashchips is geplaatst. Micron maakte tijdens de vorige week gehouden Solid-State Circuits Conference bekend te werken aan de chip, maar liet daar volgens Eetimes ook weten nog niet te hebben besloten of het ontwerp daadwerkelijk op de markt komt.

Micron maakt gebruik van floatinggatetransistors bij de tlc-geheugencellen. Dit is het meestgebruikte type transistor voor planar flash-nand, maar Samsung gebruikt voor zijn 3d-V-nand zijn zelf ontwikkelde charge-trap-geheugencellen. Analisten claimen tegenover Eetimes dat Samsungs methode duurder en complexer is dan de traditionele floating-gatetechniek. Bij floating-gatetransistors zijn de elektronen opgeslagen in de geleidende laag van de floating gate, bij charge trap in de isolerende laag om een channel, waarbij Samsung het ontwerp verticaal toepast en gebruikmaakt van interconnect-via's door de geheugenlagen.

Microns chip zou een relatief grote blockgrootte van 96MB hebben en geen partieel beschrijven en wissen van geheugenblokken bieden. Dit brengt nadelen met zich mee voor efficiënt geheugenbeheer, het toepassen van trim en, uiteindelijk, voor de snelheid.

Geheugenfabrikanten zijn in een race verwikkeld om de datadichtheid te verhogen en de kosten binnen de perken te houden. Het is Samsungs strategie om het aantal lagen van zijn 3d-V-nand te verhogen; het bedrijf brengt momenteel geheugenchips van 48 lagen uit en claimt 100 lagen te kunnen stapelen. Toshiba/Sandisk heeft 48-laags 256Gbit-tlc gereed en zou eind 2017 op 768Gbit kunnen zitten met zijn BiCS-technologie. SK Hynix zou begin 2016 zijn 48-laags 256Gbit-tlc gaan produceren.

Update, 17.15: In het artikel stond abusievelijk dat de schrijfsnelheid van de Micron-chip 53MB/s is, maar dat moet 44 MB/s zijn.

Product	Oppervlak	Opslagdichtheid
Samsung V-nand 128Gbit-mlc 24 Layer	133mm²	0,96Gbit/mm²
Samsung V-nand 128Gbit-tlc 32 Layer	68,9mm²	1,85Gbit/mm²
Samsung V-nand 256Gbit-tlc 48 Layer	97,6mm²	2,6Gbit/mm²
Micron 2D-nand 128Gbit-mlc	147mm²	0,87Gbit/mm²
Micron 3D-nand 384Gbit-tlc	168,5mm²	2,28Gbit/mm²
Micron 3D-nand 768Gbit-tlc (prototype)	179,2mm²	4,29Gbit/mm²

3D-NAND	Lagen	Capaciteit	Productie/Verkrijgbaarheid
SK Hynix 3d-nand	36	128Gbit (mlc)	Q4 2015 / 2016
SK Hynix 3d-nand	48	256Gbit (tlc)	Q1 2016 / ?
Samsung V-nand Gen 3	48	256Gbit (tlc)	Augustus 2015 / ?
Samsung V-nand Gen 2	32	86/128Gbit (mlc) 128Gbit (tlc)	Mei 2014 / H2 2014
Samsung V-nand Gen 1	24	128Gbit (mlc)	Augustus 2013 / H2 2013
Toshiba/SanDisk BiCS	48	128Gbit (mlc)	H2 2015 / 2016
Toshiba/SanDisk BiCS	48	256Gbit (tlc)	H1 2016 / 2016
Intel/Micron 3d-nand	32	256Gbit (mlc) 384Gbit (tlc)	Q4 2015 / 2016
Laatste cijfers van: oktober 2015, bron:Computerbase

Reacties (29)

Kloppen de eenheden wel? Moet Gbit niet GByte zijn?

De opslagcapaciteit van een geheugenchip wordt, om wat voor reden dan ook, altijd in bits vermeld. Ja ze kloppen in dit artikel.

Omdat een byte niet veel zegt. We werken vandaag dan wel met bytes van 8bit, maar er is geen enkele reden waarom je een byte niet groter of kleiner kunt maken. De correcte definitie van een byte is dan ook "het kleinst addreseerbare gedeelte van het opslagmedium".

Stel dat ik bij elke byte een pariteitscheck wens in te voeren in de controller die ik gebruik, dan heb ik ineens 9 bits per byte nodig en klopt je eenvoudige conversie van delen door 8 niet meer.

Dezelfde reden waarom transmissiesnelheden bijvoorbeeld in bits per seconde worden weergegeven: het is bijna onmogelijk om op voorhand te bepalen hoeveel overhead je gaat hebben daar dit afhangt van de gberuikte protocollen.

Daarnaast word bij het gebruik in bit ook de correcte SI eenheid gebruikt daar het effectief veelvouden van 1000 zijn en niet 1024 zoals bij een byte.

[Reactie gewijzigd door Blokker_1999 op 8 februari 2016 14:49]

De correcte definitie van een byte is dan ook "het kleinst addreseerbare gedeelte van het opslagmedium".

Dus DDR4-geheugen heeft bytes van 64bit? En harde schijven hebben bytes van 512byte4096bit, of zelfs 32768bit tegenwoordig? Enz

De historische definitie van "byte" is "geheugen-eenheid voor één karakter" en/of "kleinst addresseerbare geheugeneenheid door de CPU (niet opslag!)", wat in de meeste gevallen hetzelfde is.

En tegenwoordig is een byte de facto 8 bit.

Stel dat ik bij elke byte een pariteitscheck wens in te voeren in de controller die ik gebruik, dan heb ik ineens 9 bits per byte nodig en klopt je eenvoudige conversie van delen door 8 niet meer.

Klopt, dat is inderdaad één van de redenen dat geheugenchips in bits gespecificeerd worden - maar ook bv SATA of PCIe link speeds, waar nog een 8b/10b encoding overheen gaat.

Maar dat heeft meer te maken met op welk niveau je bezig bent. Op een laag niveau, dicht bij de hardware, heb je het over bits of bits/sec. Op een hoger niveau, laten we zeggen in het OS, heb je het al snel over bytes, sectors, of blocks. Op een nog hoger niveau, de gebruiker, praat je over 1000-based mega- of giga-bytes.

En Micron maakt geheugenchips. Low-level hardware dingen. Dus bits
[/q]Daarnaast word bij het gebruik in bit ook de correcte SI eenheid gebruikt daar het effectief veelvouden van 1000 zijn en niet 1024 zoals bij een byte.[/quote]
Zoals .oisyn al zei: niet bij geheugenchips dus. Deze chips zijn dus 768Gib (gibibit), niet 768Gb (gigabit).

Man, wat klinkt gibibit stom

Mwoeah; een byte zal altijd een byte blijven hoor.
De noemer byte is een samentrekking van "By Eight" waarmee "per 8" (bits) bedoeld wordt.

Wat jij op doelt is de overhead die bij de techniek komt kijken en die wisselt afhankelijk van het niveau waar je kijken.
Op geheugen niveau heb je bij ECC bij de pariteitscorrectie los van het extra bitje om een fout te herkennen ook nog een extra byte + bit nodig om de evt. correctie uit te voeren.

Wanneer ik een integer wil opslaan in een database gebruik makend van MySQL heeft kan dit onderhuids best heel wat meer bitjes doen omklappen dan het op 't eerste gezicht lijkt.
Zo kan de data op een RAID array gehuisvest zijn en zou er een index op dit attribuut aanwezig kunnen zijn.

Om de overhead gevende technieken uit te sluiten houdt men nog steeds het basis begrip in Bit's aan.

De strekking van waar je op doelt bedoelt kan inderdaad mogelijk wel veranderen.
Mocht men andere opslageenheden gaan aanhouden dan zou de Byte in het geheel kunnen verdwijnen en vervangen worden door iets anders.
Zodra de opslagvorm bijvoorbeeld van bit naar een Qbit zou gaan zou je het over Gqbytes kunnen hebben oid.
Met als gevolg dat 2 qbit's in toestanden evenveel "data" kunnen huisvesten als 3 bit's.

Interessante uitleg van "By eight". Ik heb deze uitleg zelf nooit gehoord, en als ik google kom ik uit op zie ik niet direct veel referenties hierover, behalve:

http://www.wordorigins.org/index.php/bit_byte/

Ze maken niet direct melding over "By Eight" maar wel het volgende:

Some have suggested that it is an abbreviation for BInary digiT Eight and that the Y was substituted for the I so to prevent typographical confusion with bit. Another suggestion is that it is from BinarY TErm. Neither of these claims is well substantiated and are probably false.

Hun conclusie is dat byte een woordspel is van bit:

The term byte is of less certain origin, but probably was coined by someone at IBM (perhaps a Dr. Werner Buchholz) around 1964. The word byte is a play on bit.

Maar legt ook uit dat we tegenwoordig eigenlijk inderdaad een byte equivalent stellen aan 8 bits:

The original sense of the term was the amount of data required to represent one character—usually, but not always, eight bits. Over time, the predominant sense shifted to mean eight bits exactly.

Dat zal verwacht ik ook niet meer veranderen, een byte is compleet ingeburgerd. Echter kom je ook een heel eind door gewoon het aantal bits te benoemen. Zo zijn operating systems gewoon aangeduid met 16 / 32 / 64 bits, en niet 2 / 4 / 8 bytes. Ik denk dat het geen exacte wetenschap is wat we met bits en wat met bytes aanduiden.

[Reactie gewijzigd door A Lurker op 8 februari 2016 17:19]

Volgens mij is het woord byte vooral een woordspeling geweest en hebben al deze woorden betrekking op een 'hapje' uit het geheugen in oplopende grootte: bit, nibble, byte

Ik heb er even op gegoogled in zie inderdaad dat wat jij (en onderstaande tweakers) melden in ieder geval mijn statement ontkracht.
Dit is wat mij ca. 15 jaar geleden op school is "geleerd"; beetje jammer.

Dank voor de correctie *allen

"byte is een samentrekking van "By Eight""

Het zal halverwege de jaren 1970 zijn geweest dat ik voor het eerst met byte (opslageenheid) en Byte (het tijdschrift) in aantaking kwam, maar deze uitleg heb ik nog nooit gehoord. Ik vraag me af waar je dit vandaan hebt. In ieder geval niet van wikipedia, die in dit geval accuraat is.

Dit schijnt in de "The Hacker's Dictionary,Eric S. Raymond" te staan:

"The term was coined by Werner Buchholtz in 1956 during the early design phase for the IBM Stretch computer; originally it was described as 1 to 6 bits (typical I/O equipment of the time used 6-bit chunks of information). The move to an 8-bit byte happened in late 1956, and this size was later adopted and promulgated as a standard by the System/360. The word was coined by mutating the word 'bite' so it would not be accidentally misspelled as bit. "

of

http://www.bobbemer.com/BYTE.HTM

Oftewel de oorsprong is eigenlijk de 8 bits die gebruikt werden voor de ASCII characters.

ASCII is nieuwer (1963): en heeft 7 bits:
https://en.wikipedia.org/wiki/ASCII

De rest van de quote staat ook op wikipedia:
https://en.wikipedia.org/wiki/Byte

Maar er staat niet dat het komt van "By Eight". En die heb ik ook nog niet gehoord.

In deze talk wordt het genoemd en ontkracht:
https://en.wikipedia.org/wiki/Talk%3AByte

A "byte" was usually less than eight bits in the early years of the use of the word. -R. S. Shaw 03:46, 10 May 2006 (UTC)

Daarnaast word bij het gebruik in bit ook de correcte SI eenheid gebruikt daar het effectief veelvouden van 1000 zijn en niet 1024 zoals bij een byte.

En dát is dus bij geheugenchips over het algemeen niet waar, omdat het veel efficienter is om een deling door tweemacht te kunnen doen in de addressering van het geheel.

Het zijn bits omdat dat het kleinst adresseerbare gedeelte van het medium memory chip is.
Dat wordt gedaan vanwege het feit dat dit de meest praktische methode is.
Als er een extra bit als pariteit nodig is, dan zetten ze gewoon 1 chip extra op de memory module.

Overigens zitten er in dit nieuwe prototype 824633720832 bits en geen 768000000000 zoals je aangeeft.

[Reactie gewijzigd door Alfa1970 op 8 februari 2016 16:04]

Aangezien SSDs geen eigen leven leiden, maar (nagenoeg altijd) onderdeel zijn van een groter geheel, is dit wel een erg stricte interpretatie van het woord byte. Op de NL wiki staat wel iets wat jouw verhaal onderbouwt (zie https://nl.wikipedia.org/wiki/Byte, en het woordje 'de facto'), maar in de praktijk zal een programmeur of applicatie iets moeten aannemen. In ieder geval is dat niet < 8 bits, maar >= 8 bits voor een byte. Je opmerking over 'kleiner maken' kan in principe niet voor de taal C (en dus programmeurs), maar wellicht wel voor TLC of andere multi-level NANDs?

Voor alles wat met file systemen te maken heeft (alle UNIX & Windows varianten die ik ken) is toch echt 8 bits = 1 byte. Dat er her en der eventueel pariteits bits gebruikt worden, is verborgen voor de afnemer van het opslag medium. Ook in programmeertalen is 8 bit = 1 byte (en nog een rijtje typen waar standaarden voor zijn, zie bijv. de ISO/ANSI C standaard). Veelal formuleren standaarden zich als 'de minimale grootte waar een pointer in moet passen' of 'de minimale grootte waar een integer waarde in past', maar in de praktijk hanteren (bijna) alle platformen dezelfde waardes.

De rekening met 1000-tallen uit SI is iets wat de marketing afdeling van opslag media doet. Het file systeem zelf werkt weer met KiB, MiB, GiB. Het is jammer dat deze verwarring is ontstaan.

Soms heeft zo'n chip ook geen hele byte per adres en moet je er een paar parallel zetten zoals op een geheugen reepje. Het zou dan eigenlijk ook fout zijn om van bytes te spreken.
Al denk ik dat hier wel (minstens) bytes uit komen.

Denk het ook ja, wellicht in de war met GibiByte en GigaByte?

1 gigabyte (GB) = 1000 * 1000 * 1000 bytes
1 gibibyte (GiB) = 1024 * 1024 * 1024 bytes
dat is het eigenlijk, maar ik gebruik ze zelf ook door elkaar

Ik kan geen gat schieten in de gebruikte eenheden... welke zou niet correct zijn, en waarom?

Denk niet dat dit nu interessant gaat worden.
De chip ongeveer 90 GiB, maar met een write snelheid van 53MiB/s zou je er dus 10 nodig hebben om op een goede snelheid te komen of een hele goede writecache moeten hebben.
Wel lekker dat je dan tegen de 8 GiB/s read hebt

Je zou ook kunnen denken aan een meer hybride oplossing, vergelijkbaar met wat je nu ook hebt met HDD's met een SSD-cache aan boord.
Dus een snel deel met SLC flash voor de hoge schrijfsnelheid van data wat veel veranderd en dit soort chips voor hoge opslag-capaciteit voor data die niet veel verandert.
En hoe vaak heb je nu werkelijk die hele hoge schrijfsnelheid nodig? Als je zeg een 100 GByte aan snel geheugen hebt en TB's aan relatief langzaam geheugen, maar toch snel leesbaar, dan is dat toch ook een prima oplossing?

Deze chips zijn niet bedoeld voor normaal gebruik, anders wil je naast de snelheid ook dat TRIM goed werkt wat volgens het artikel met zulke blokgrootes een probleem kan zijn.
Dit is voor een streamingdienst interressant. Goede leessnelheid en grote capaciteit zijn daar van belang. Er hoeft niet vaak een nieuwe films opgeslagen worden, dus is de schrijfsnelheid minder belangrijk. De films die opgeslagen zijn zullen ook voor lange tijd opgeslagen blijven. Zolang je (bijna) niks verwijderd heb je de TRIM functie nouwelijks nodig.
Voor normaal gebruik is dit niet interessant, voor specifieke doeleindes perfect.

[Reactie gewijzigd door Musical-Memoirs op 8 februari 2016 16:14]

De 3d-nand-chip van Micron biedt maximale sequentiële leessnelheden van 800MB/s en schrijfsnelheden van 53MB/s

Nogal een verschil tussen lezen en schrijven. En met 10 van deze chips parallel haal je nog maar sequentiele schrijfsnelheden van zo'n 530 MB/s. Voor een SATA600 SSD is het voldoende en ongeveer de maximale doorvooersnelheid van de interface, maar voor PCI SSD's lijkt het me niet voldoende.

Het is nog erger, als je het orginele artikel leest zie je dat die 53MB/s voor de Samsung is, en deze Micron het moet doen met 44MB/s. (fout overgenomen door Tweakers) inmiddels gefixt

[Reactie gewijzigd door u_nix_we_all op 8 februari 2016 20:38]

Ja je heb gelijk, scherp .

The Micron part has much faster read times at 800 Mbytes/s compared to 178 Mbytes/s for Samsung. However the Korean giant wins on write times at 53 Mbytes/s compared to 44 Mbytes/s for Micron.

"Analisten claimen tegenover Eetimes dat Samsungs methode duurder en complexer is dan de traditionele floating-gatetechniek"
Interessant om te weten, helemaal gezien het feit dat de Samsung SSD's een goede prijs/kwaliteitverhouding hebben. De kosten zitten hem ook vooral in het "flash" (want een SSD bestaat uit bijna niets anders).

Misschien gaan andere zaken in het traject grondstof-eindgebruiker efficiënter, of Samsung maakt gewoon erg goede controllers of zoiets.

Ik vind die goede prijs/kwaliteitsverhouding wel mee vallen.
De pricewatch: Samsung 850 EVO 250GB is meer dan 20% duurder dan z'n grote concurrent, de pricewatch: Crucial BX200 240GB

Ik kan niet wachten tot dat ze de memristor op de markt introduceren.
Gedaan met die geheugenproblemen dan.

Mooi nou op naar de Petabytes!

edit: Nevermind, ik lees niet goed

[Reactie gewijzigd door Rutje! op 8 februari 2016 15:27]