Slashdot Mirror
Samsung Demos Future Memory Chips
Fletcher points to this story in CNET Asia, excerpting "The Korean electronics giant unveiled an 8-gigabit flash memory chip Monday based on the 60-nanometer process, as well as a 2-gigabit DDR DRAM chip based on the 80-nanometer process. Flash chips, which retain data after a host computer is turned off, are used in flash cards and cell phones, while DDR DRAM is used inside PCs."
People tend to get excited about new products like these; in a separate but equally relevant phenomenon, they tend not to RTFA.
From the article:
Both chips, however, are prototypes. Companies just began this year to make chips on the 90-nanometer process. (The nanometer measurement refers to average feature sizes on the chips). Eighty-nanometer chips may not come for at least another year, and 65-nanometer chips won't debut until at least the end of 2005.
In other words, 16GB flash MP3 players will not be available in time for Xmas.
I want to drag this out as long as possible. Bring me my protractor.
One gigabit is 128MB. Assuming a 64-bit memory bus width, one chip per bus bit, and 2 gigabits of storage per chip, you're talking about a 16GB DIMM.
So the the terminology inclined, it is a significant advancement.
A good summary of memory technology is here.
tasks(723) drafts(105) languages(484) examples(29106)
The manufacturers of the actual silicon will always use *bit for the size because they are developing something independant of architecture, and therefore *bit is the most relevant notation of size. On a PC it might be relevant to use 'quads' as a measurement, as all machine code and addressing is done in 32 bits, whereas on some older microcontrollers the addressing is in 4 bits, so that would be nibbles. Perhaps some technologies want single-bit accessability, as the storage is not used to store addresses/instructions/ASCII. Using *bit is the only truly platform independant measurement, because the 8-bit bytes is aribtary whilst the bit is indivisible.
#include "disclaimer.h"
They are using conventional storage standards. Memory chips have been measured in (multiples of) bits for decades. When I started paying attention, around 1980 or so, the state of the art was something like 4k or 16k bits for DRAM and those chips were 1-bit wide. Even 8-bit wide chips were, and still are, quoted with storage capacity in bits. Again from the early days, an EEPROM with 2048 words of 8-bits each was described as a 16k device.
Further down in the article it is stated that "The flash chip is designed to let consumer electronics designers put up to 16 gigabytes of data on a single memory card". Note that they use the conventional units, bytes, for memory cards.
Remember, different conventions in different fields. You may think its silly, but that's life and you'd better get used to it.
And, since you ask: no, bits doesn't necessarily imply a rate connectivity. Raw connections are usually rated in bits per second but high level data streams, such as ftp download speeds, are often quoted in bytes per second. I do not know whether there is a parallel here between comms and storage in the different conventions used to specify what the raw technology gives you and what is built out of that technology. I would be interested to learn whether it is more than coincidence.
Paul
Lasciate ogne speranza, voi ch'intrate
Actually, there are plenty of reasons to measure bandwidth in bits not bytes.
When I size/plan/order circuits, I need to know raw throughput in bits/sec, because I may be ordering that circuit for a dedicated purpose, which can have significantly different overhead and efficiency than a different purpose.
Whenever you see bandwidth measured in Bps (bytes per second) you are seeing, at best, an estimate. The reason is that people are concerned about *payload* when you mention bytes, not raw throughput.
As overheard increases or decreases per packet (which can be caused by fragmentation, poor application design, etc), then the amount of payload data per packet changes, while the raw throughput does not. Try this as an exercise. Open up an FTP sire via MSIE, and transfer a large file from a decent server near you. Note how long it takes, and the data rate MSIE tells you that it comes in at. Now, open up an MS command prompt, and ftp to that same site, get the same file, and note how long it takes, and the data rate it tells you.
Same site, same link, same file, same OS...two completely different download times/rates.
When I order any circuit...I want to know what the actual bit rate of the line is. I don't want some marketing mumbo-jumbo about 'bytes per second'...I may not even use an 8 bit byte, or, they may use a different interpretation of 'kilo' and 'mega' when quoting data rates. Bit-rate is pure...because a bit is a bit is a bit, and a second is a second is a second.