Slashdot Mirror
IBM Claims World's Smallest SRAM Memory Cell
nokiator writes "IBM issued a press release today claiming that it has built an SRAM memory cell that is ten times smaller than those currently available.
My interpretation of the PRese in this release is that IBM will be able to build 256Mb or 512Mb SRAM chips or integrate 32MB or more SRAM into processor dies for cache applications in the future. Of course, showing some SRAM cell prototypes is a long ways from being able to manufacture this technology in a cost effective way.
There is no information in this PR about the speed or power consumption of SRAM blocks that can be built with this new cell technology. This is not likely to be a potential DRAM replacement for mainstream applications as DRAM already offers more than ten times density compared to SRAM at much better cost."
...they can only store zeros. They are working feverishly on scaling them up to store ones.
And people keep asking me why we don't buy servers from Dell. Maybe I'm old-fashioned in thinking that a company that continuously innovates the technology and not the distribution or marketing channel is whom I should get my technology from...
This is not likely to be a potential DRAM replacement for mainstream applications as DRAM already offers more than ten times density compared to SRAM at much better cost."
I thought the PR implied "Although not as dense, SRAM is many times faster than dynamic random access memory (DRAM).", density is like a also-run.
Rock that crushes, Paper & Scissors that don't matter.
There's so many things wrong with this post...
a) the 64-bit CPUs that exist today have 32-bit instructions.
2) just because the width of the registers is 64-bit does not mean that all data that is processed is now 64-bit wide, 64-bit CPUs are certainly capable of processing 32-bit values.
D) somehow having a value stored as 64-bits doesn't mean you can use it for twice as many things as the same value stored as 32-bits (assuming it fits) or somehow all of your programs/algorithms can use the value twice as much as before (implying twice the work)
The memory modules you put in your computer are composed of DRAM chips. DRAM uses a capacitor and a transistor per cell (plus sense amps, decoders, etc.). DRAM requires refresh (the charge on the cap leaks off) but is relatively low-power and very dense. SRAM uses no capacitors, but more transistors (4 or 6) per bit; it's higher-power but faster and doesn't require refresh.
So, SRAM density has nothing to do with DIMMs you put in a computer. It's used for on-chip caches (and off-chip caches), but is too expensive for main memory. Denser SRAM means that Opteron you've got with 1M L2 cache could have 4M or 8M if IBM can mass-produce the stuff.
DIMMs usually have 16 chips (18 for ECC modules). So, if you have 512Mbit DRAMs, you put 16 of them on a module and you get 8Gbit = 1Gbyte. Gigabit DRAMs can make 2GB DIMMs. 2Gbit DRAMs are needed to make 4GB DIMMs; they cost hundreds of dollars each (and you need 16!), which is why 4GB DIMMs are so amazingly expensive.
High-speed Road Trip (18.000KPH)
That is not true at all. The size of instructions is still 32-bits for all 64-bit RISC CPUs and the instruction size is the same in x86-64 as that of regular x86 (CISC). Now 64-bit CPUs give you the *option* to use 64-bit data/pointers, but you are free to continue using 32/16/8 bit data as you deem appropriate. Code/data size doesn't automatically increase.
Also, you may not necessarily be doing twice the work with a 64-bit CPU - it again depends on your compiler. In theory you *can* do two 32-bit operations in parallel using a 64-bit EX/FP unit if the ISA provides for packed operations (also known as SIMD instructions).
Of course, showing some SRAM cell prototypes is a long ways from being able to manufacture this technology in a cost effective way.
Well, were still talking about IBM here? Do you really think that a few hundred dollars more would even get noticed at clients that buy a server in the 100K range?
The main advantage of buying high-end gear from IBM, Cisco and the like isn't that you get cheap hardware ('cause you simply don't). You buy the gear from that company because you get 10 years in-house service including remote failure detection if you pay for it. That means, THEY call YOU before you even notice one of your tripple-redunant drives has problems. At this point in time, the technician is probably already on the way up to your office.
Sure, it's very expensive. But you save quite a lot by not having any significant downtime...
Seen in that context, 500 bucks more for RAM is IMHO just irrelevant to even think of...
Look, this thing is totally safe! Built it myself, you know. You just press that button like this and then turn that lev
However, I wonder if the additional implementation requirements justify the benefits. Static typing is only found in certain computer languages, and programmers have come to rely on dynamic memory allocation offered by malloc() or similar routines. I suspect with careful design one could fully exploit the advantages present -- with software being cheaper than hardware, it could easily be well worth it in embedded or pre-fabricated devices.
The type of implementor that uses (dynamic) extreme programming methodologies may be left out in the cold, although I would like to suggest that would occur anyway to a person working without a blueprint. Regardless, it will be exciting to see how this develops from the embedded perspective...
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Comment removed based on user account deletion
Huh? What you say makes little sense. While it is true that smaller caches with less associativity respond faster, there is no "search through them more quickly" as it is all done in parallel. What makes it faster/slower is the depth of match logic required when you have many way set associativity (all the way up to fully associative which is the most expensive).
Secondly, why in the *world* would you not want to cache more data if you could? Ideally, all of your main memory would be just a large one-way set associative cache for best performance. (Compaq once made a 386 machine that had all SRAM as its main memory. No wait states at all and it was *fast* *fast* but it was also *expensive* *expensive* and upgrades for the memory were incredibly expensive.)
I'm thinking that this post must have been a failed attempt at humor.
Excuse me, but isn't the cost of any feature directly related to its size, making the above statement self-redundant?
I mean, a wafer-start is a fixed cost, divided by the number of processors it yields. That makes the area of the processor die directly relate to its cost, and the size of any feature relates to its subcost portion of the overall processor cost.
Or in simple terms: Smaller features should always cost less because you get more of them per fixed cost wafer.
Am I missing something major here?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
You, sir, are the man.
You convinced at least five posters that you were serious while simultaneously spouting an illogical collection of computer-related jargon and utterly false statements. I expect to see you here again on April 1st.
Mod me down and I will become more powerful than you can possibly imagine!
Actually, it used to be based solely on the width of the general purpose registers in the CPU, implying that the CPU could process data in those sizes with one ALU operation (the ALU was as wide as the general purpose registers).
The 68000 you mention was considered a 32-bit CPU, or at least a 32/16 (32-bit internally, 16-bit data bus) as was the 68010 and it wasn't until the 68020 when it had a 32-bit data bus as well. There was even a variant that was the 68008 that was identically equivalent to the 68000 except it had an 8-bit external data bus. I have occassionally seen the 68000 referred to as a 16-bit processor, but the vast majority of times I've seen it discussed call it a 32-bit CPU.
As far as I remember, no processor has ever been 'named' relative to the address bus width. Even in the PC world I can't remember any time when the CPUs were 'named' relative to the address bus. Many 32-bit CPUs didn't have the full 32-bit address bus externally accessible. I can't think of any 64-bit CPU that has the full 64-bit address bus externally accessible.
As far as cache storage of data, the data formats are independent of the pointer size. The blanket statement that a 64-bit CPU effectivly 'halves the cache' is not true. If you have a program that deals only with pointers, then you'd have a point but 'int' on a 64-bit CPU is the same as 'int' on a 32-bit CPU (both being 4 bytes or 32-bits). It *is* true that a program compiled for 64-bit ISA will use *some* more cache, but that is entirely dependent upon the program itself. Again, a program that uses pointers a lot may use more cache than the same code on a 32-bit architecture, but a program that uses few pointers may not use much more (if any more) than the 32-bit counterpart, depending upon the datatypes used.