'Universal' Memory Aims To Replace Flash/DRAM

siliconbits writes "A single 'universal' memory technology that combines the speed of DRAM with the non-volatility and density of flash memory was recently invented at North Carolina State University, according to researchers. The new memory technology, which uses a double floating-gate field-effect-transistor, should enable computers to power down memories not currently being accessed, drastically cutting the energy consumed by computers of all types, from mobile and desktop computers to server farms and data centers, the researchers say."

Comments

10 Years away

[Anonymous Coward]

This technology always seems to be less than 10 years away.

Re:10 Years away

[gmuslera]

I hope that xkcd is wrong this time. Would be nice to have most new mobile devices with that in 2 years.

Re:10 Years away

[spazdor]

And post about it anonymously on the internet, in the middle of entirely unrelated conversations. Yeah, damn those man-haters.~

Re:10 Years away

[TopSpin]

This technology always seems to be less than 10 years away.

There may be hope for this one. These researchers appear to have confidence enough not to adopt usual 5 year microelectronic SPI.

Re:10 Years away

[couchslug]

"This technology always seems to be less than 10 years away."

Eventually, (less than ten years away) technology to produce technology predicted to be less than ten years away in less than ten years will be fielded.

But I like volatility!

[melikamp]

Volatility is actually useful for certain security policies: like storing sensitive passwords in computer memory and working with temporarily decrypted files.

Re:But I like volatility!

[pushing-robot]

The first floating-gate in the stack is leaky, thus requiring refreshing about as often as DRAM (16 milliseconds). But by increasing the voltage its data value can be transferred to the second floating-gate, which acts more like a traditional flash memory, offering long-term nonvolatile storage.

Re:But I like volatility!

[Simon80]

Volatile memory is already vulnerable to reboot attacks, because the data takes a long enough time to rot. Paradoxically, non-volatility could increase security in these cases by making it more obvious that it's not OK to leave sensitive info sitting around in memory.

Re:But I like volatility!

[TooMuchToDo]

Very true. Don't rely on assumed physical traits. When in doubt, wipe like the $three_letter_agency is at the door.

Re:But I like volatility!

[Anonymous Coward]

Simtek _used to_ make a memory like that called nvSRAM back in the 1990's by combining SRAM with EEPROM.
I have the databook sitting right in front of me right now. Someday I might fetch some $$$ selling it on ebay.

I hope they solve the issues of limited write cycles for the FLASH cells. Not sure if it would suffer the same high READ errors rates as NAND FLASH.

Re:But I like volatility!

[mypalmike]

Also, we lose the "just reboot it" fix for all the crappy software we write.

Re:But I like volatility!

[SanityInAnarchy]

Why? I mean, "rebooting" is still possible, it just sucks that much more since there'd no longer be any hardware reason to do so.

Re:But I like volatility!

[purpledinoz]

I read somewhere that if you cool DRAM, the data can stay intact for up to 10 minutes. That's plenty of time to remove the modules and extract the data from them. But if this is really a big concern, I wonder if it's practical to zero the memory after a PC is shutdown. Kind of a background routine. Or maybe even short all the lines to drain the stored charges.

Re:But I like volatility!

[squizzar]

When your memory's nonvolatile
Nothing is forgot, nothing is forgot, nothing is forgot

If your bits try to get at you
flip 'em with a not, flip 'em with a not, flip 'em with a not

security isn't easy y'all,
no it's fsckin not, no it's fscking not, no it's fscking not

With a triple-des key in some volatile ram,
encrypt all your memory and hide it from the man?

Re:But I like volatility!

[lga]

Not so; but rebooting would have to include zeroing all of the memory. Starting up and resuming with the contents intact would be more akin to coming out of sleep mode.

Re:But I like volatility!

[ultranova]

But if this is really a big concern, I wonder if it's practical to zero the memory after a PC is shutdown. Kind of a background routine. Or maybe even short all the lines to drain the stored charges.

Why would you sell computers with such features? Are your customers terrorists?

Re:But I like volatility!

[kasperd]

I wonder if it's practical to zero the memory after a PC is shutdown. Kind of a background routine.

If you want the hardware to be modified slightly to achieve it, then it should be completely practical. DRAM doesn't write individual cells at a time. It reads out entire lines of bits into SRAM modifies it there and writes it back. Moreover it even periodically sweeps over the lines just reading them out and writing them back to refresh them.

I don't know how long time the sweep takes, but for wiping the memory you could speed it up. The control logic have a number of outgoing lines with a binary number indicating which line of cells to read or write. Each line has a decoding unit to know when its number is up. If you added a line to select all lines simultaneously and OR that line with the output of the existing decoding unit, it sounds feasible that the control logic could in fact write the contents of the SRAM to all lines in parallel.

If this works you could wipe memory in less than a microsecond.

Re:But I like volatility!

[kasperd]

but rebooting would have to include zeroing all of the memory.

Not necessary. The operating system already has to assume there could be random garbage in all the memory it didn't touch. The operating system has to zero the memory before handing it to applications. And that is the case even if it was zeroed on boot. It could be a long time since the system was booted, and the memory may have been used for something in the meantime. Some operating systems keep a cache of zeroed pages that can be handed to applications as needed, others do it on demand.

Re:But I like volatility!

[kasperd]

Indeed. The number of possible write cycles is important if you wanted to replace RAM. I'd wish we had a kind of memory with all the properties that would be important to use it as swap space. That means many write cycles, performance better than flash and hard disk (but not necessarily as fast as DRAM), and finally price and density that is closer to flash than to DRAM.

Fast and durable does have its places. Imagine if you could design a computer where you didn't have to worry about losing power for a short period of time because once the power returned, the entire contents of RAM would still be there and you could just resume where it left off. It would eliminate the need for a UPS in some places (but not in all places). And it would mean you didn't have to ensure that your laptop was suspended before battery runs out, and you don't lose what you were working on in case the battery does run out while suspended.

Re:But I like volatility!

[maxwell demon]

Actually rebooting just would need to zero/replace a few crucial data structures, just as a normal file system format doesn't overwrite all data, but only replaces the superblock (or whatever central data structure the file system in question uses) to mark the rest of the covered space as free and usable.

Re:But I like volatility!

[hitmark]

So they have crammed two sets of "hardware" onto the same physical chip, and transfer data between them depending on the state wanted. Why no just sell flash in DIMM modules and do the same at the chipset level?

Re:But I like volatility!

[marcosdumay]

It certanly has a reset pin...

Re:But I like volatility!

[somersault]

Imagine if you could design a computer where you didn't have to worry about losing power for a short period of time because once the power returned, the entire contents of RAM would still be there and you could just resume where it left off.

I have one of those at work, I call it a laptop (well, a netbook). We had a power cut for a while last week, some of the UPSes ran out, but my netbook was fine :)

And it would mean you didn't have to ensure that your laptop was suspended before battery runs out, and you don't lose what you were working on in case the battery does run out while suspended.

Use hibernate instead of suspend. Admittedly hibernation has been pretty buggy on some of the OS/laptop combinations I've had over the years.

I do think this stuff would be very cool for power savings when the machine is in use though.

Re:But I like volatility!

[Thing 1]

Why would you sell computers with such features? Are your customers terrorists?

No, bankers. But then I repeat myself.

Re:But I like volatility!

[GameboyRMH]

LMAO Mod parent Funny! XD

Re:But I like volatility!

[tlhIngan]

I read somewhere that if you cool DRAM, the data can stay intact for up to 10 minutes. That's plenty of time to remove the modules and extract the data from them. But if this is really a big concern,

One trick I used for debugging (I had no way to log to a serial port in the OS I was using) was to log to memory. The system would crash, then I would simply reboot it, and then dump the log buffer out via the bootloader.

Even after several seconds, the log was still quite readable.

That paper on reading hard drive bit patterns that lead to the 31 pass erase had a section on semiconductor memory as well, where he found that DRAMs have this ability despite the charge leaking off due to cell effects - a cell holding a 1 is more likely to hold a 1 for seconds to minutes upon powerup, and ditto for a 0. It doesn't power up quite so randomly. This effect is stronger on memory that isn't changed frequently.

This also annoyed me to no end because another OS would test memory for a signature, which if present, meant it had a usable RAM disk... which was corrupted because it was off for a few minutes. It would hang on boot until we cleared the signature from RAM...

Re:But I like volatility!

[kasperd]

Use hibernate instead of suspend.

I have seen computers where one work and the other doesn't. But I'll have to admit, that most of my issues with it could be resolved by fixing the software, and no new hardware would be required.

With the laptops I currently have, the situation is as follows. My work laptop (MacBook Pro) is configured to automatically suspend to RAM and disk simultaneously. And this works flawlessly until it actually need to resume from disk at which point it crashes and reboots. My older personal laptop by default suspend to RAM and crash when resumed, but if I remember to suspend to disk it does actually resume just fine 95% of the time. My newer personal laptop by default suspend to RAM as soon as I close the screen, and it resumes just fine. I didn't try to figure out how to make it suspend to disk.

There is a couple of general issues with the suspend functionality. If storage encryption is in use, most implementations suffer from the serious flaw of keeping the key around while suspended. They make this mistake both when suspending to RAM and when suspending to disk. However I believe extracting the key from RAM requires a bit more skill than extracting it from disk.

Finally the estimate of how much battery is left is not always accurate enough to have the system automatically suspend before power runs out. And this may be the only issue on my list that would require hardware changes to fix. All the other ones are simply software bugs that need to be fixed.

Re:But I like volatility!

[mattack2]

The hardware reason is because the hardware uses electricity, even in sleep. Yeah, I know, most people don't care about that.

Re:But I like volatility!

[SanityInAnarchy]

It doesn't in hibernation.

Regardless, this is a technology which would make that hardware reason go away. As I read it, it's basically a much, much faster form of hibernation.

Re:But I like volatility!

[Phopojijo]

Soooo then when you unallocate memory you n-times random overwrite it.

Re:But I like volatility!

[Phopojijo]

FDA?

Early DRAM

[DCFusor]

though it had a short refresh time spec, would actually hold nearly all the bits for up to a minute, and we made early "digital" cameras out of them, charging up all the bits and letting light discharge the lit up pixels quicker than the others. It was a bit of a bear to figure out the pixel layout -- it wasn't in order, but we did it and even got to two bits or so per pixel resolution by taking more than one shot after a charge, different exposure times. One wonders why someone doesn't just work along those lines. Seems to me for most uses simply increasing the refresh time interval would save tons of power, and also complexity. If you could get it to a couple of days, I'd think that would be fine for most all portable devices, and you'd just use cheap flash as the disk, like now. I am guessing you'd lose some density, as the older, less dense DRAMs had large cells that stored more charge per bit, and that new lower voltage semis are also leakier, but it might be worth looking into anyway. I recall one case where the company I worked for designed some very early disk cache controllers. Well, actually I did about 90% of that. We used DRAM, but simply arranged the code so the basic idling operation (for example, looking for io requests or sorting the cache lookup table) took care of refresh anyway, wasn't too hard at all to manage that, and of course a block read or write always did a full page refresh. Made the thing a little bit faster, as there was never a conflict between refresh and real use in the bargain. This would also be trivial an any current opsys to get done. Probably happens by accident except in real pathological cases.

Re:Early DRAM

[RotsiserMho]

Unfortunately, my guess is simply increasing the refresh time is only going to solve one problem. I'm not an expert on DRAM or anything but it seems to behave like a capacitor. Longer refresh times require larger capacitance. Large capacitance doesn't necessarily mean more power, but I think it would take more voltage to change the state of a bit (you'd have to reverse a larger charge).

Also, the biggest problem with DRAM these days is speed (reads/writes per second). The best way to increase speed (without also increasing voltage, and thus power) is to decrease capacitance since discharging a smaller charge is faster -- not to mention it would generate less heat, which leads to higher density and higher speeds, which is what the DRAM market is really after.

Re:Early DRAM

[sxeraverx]

You are correct. Currently, DRAM stores information as a N-channel MOSFET attached to a capacitor. This MOSFET is leaky. There's no getting around this leakage. This leakage acts to discharge the capacitor where the bit is stored.

You can try to decrease this leakage in a number of ways. You can increase the threshold voltage of the gate, but that means you'd have to increase the voltage the DRAM operates at as well, or else you wouldn't be able to charge the capacitor. This means you'd increase the energy-per-operation of the DRAM cell, because you'd have to charge the capacitor up more. You'd burn up more power, because the leakage is proportional to the operating voltage, but the charging energy is proportional to the square of the voltage.

Alternatively, you could increase the capacitance. But this means that the capacitor would take longer to charge, slowing down every operation. Also, doubling the capacitor size means doubling the energy it stores (and therefore burns with every operation). It also makes the DRAM cells bigger, meaning you can't fit as many on a silicon wafer.

Neither of these is what you want to do. In fact, you want to do the opposite for traditional DRAMs. It's counterintuitive, but you get more density, more speed, and less power by increasing the refresh rate (or rather, increasing the refresh rate is a side-effect of all of those). Unfortunately, lithography limits and quantum mechanics mean we're having a hard time going any smaller.

It's truly amazing what we can do. The oxide layer (essentially a layer of quartz glass between metal and silicon) on a MOS these days is 5 atoms thick. We're going to have to come up with something that relies on something other than the traditional semiconductor effects if we want to continue forward.

Re:Early DRAM

[Bender_]

Seems to me for most uses simply increasing the refresh time interval would save tons of power, and also complexity. If you could get it to a couple of days,

Yes, increasing the refresh time is indeed a way to reduce power consumption of a DRAM. The problem is that you are dealing with billions of memory cells. The median retention time of typical cells is well within the range of seconds. But there is a tiny fraction of cells (1/10000) that lose their charge much quicker, and things may get worse at elevated temperatures etc. Those cells impose limits on the minimum refresh time.

There are ways to work around this by introducing on-the-fly error correction. But this will result in a larger device and added latency, which is obviously not desired in many applications. Nevertheless, there are dedicated low power DRAMs which use this kind of scheme to increase refresh time.

Re:Early DRAM

[kasperd]

There are ways to work around this by introducing on-the-fly error correction. But this will result in a larger device and added latency, which is obviously not desired in many applications.

Aren't you going to need this on-the-fly error correction in every system where you don't want a random bitflip to happen every once in a while? I would assume the data going between the DRAM and the SRAM in the control part of the chip would always go through some ECC logic both ways, except on those chips where it was cut out in order to reduce cost.

Re:Early DRAM

[marcosdumay]

Why don't you want to reduce the conductive area (channel and poly sizes) while you increase the thicknes oxide layer? That would recude capacitance and leak rate at the same time, wouldn't it?

But I guess it would be a bicth to manufacture... Thick and smal layers of oxide, those must be quite hard to corrode at the right shape.

Re:Early DRAM

[phaserbanks]

Increasing the oxide layer thickness was part of the solution, but they couldn't do it with silicon dioxide. The newer deep submicron CMOS processes use metal gates (instead of polysilicon) with high-k gate dielectrics (like hafnium oxide). The thicker high-k materials reduce leakage while still allowing a low turn-on voltage for the transistors.

Re:Early DRAM

[petermgreen]

Afaict currently server memory generally has ECC and desktop memory doesn't.

However ECC is a game of probabilities and block sizes. Lets say your raw bitflip rate is one per 2^30 bits (I suspect in reality it's lower) and that the different bits of each word come from very different parts of the memory array. Your chance of an error in a 64-bit word is around one in 2^24 your chance of two errors in a 64-bit word is arround one in 2^48.

In other words an ECC scheme that works on a word level and can only correct single bit errors wins you a huge impromenent in reliability.

However increase the raw bitflip rate to say one in 2^10 bits. Suddenly even if you can correct single bitflips in a word you have a very real chance of running into uncorrectable errors. Afaict the only real way to get arround this without being hugely inefficiant in memory use is to increase the ECC block size and that means more latency.

Re:Early DRAM

[kasperd]

I don't know what blocksize ECC memory uses. It would make sense to use one line of the DRAM memory, because if you don't actually correct errors during refresh, then the probability of an uncorrectable error increases the longer a memory location has remained untouched. Without correction, you could be reading out bad data and writing it back. And the memory would be accumulating errors.

Interesting

[c0lo]

TFA

"We believe our new memory device will enable power-proportional computing, by allowing memory to be turned off during periods of low use without affecting performance," said Franzon.

Huh! A new chapter opens in the "program/OS optimization" - heap fragmentation will have an impact on the power your computer consumes, even when not swapping (assuming the high density and non-volatility will render HDD obsolete... a "no more swapping, everything is non-volatile-RAM, with constant addressing cost" becomes plausible).

Re:Interesting

[VortexCortex]

"no more swapping, everything is non-volatile-RAM, with constant addressing cost" becomes plausible

Wouldn't Non-Volatile memory just be called memory esp. given that, by definition, memory recalls past events.

This family of memory is not only plausible, it has existed before -- it is how the model of a "Turing Machine" operates. In fact, our first reel to reel magnetic memory systems had this "non-volatile memory" of which you speak due to the absence of large quantities of RAM (we had sequential access memory instead), programs were executed as read from tape, and variables were often interleaved with instruction codes because seek time was a huge performance issue.

On another note: Perhaps the "no more swapping" model you speak of would draw less power if it used swapping to help cope with fragmentation? Or, perhaps each allocation unit (page), could be turned on or off individually.

Re:Interesting

[c0lo]

"no more swapping, everything is non-volatile-RAM, with constant addressing cost" becomes plausible

Wouldn't Non-Volatile memory just be called memory esp. given that, by definition, memory recalls past events.

How far back to recall and still be named a memory?

This family of memory is not only plausible, it has existed before -- it is how the model of a "Turing Machine" operates.

Yes, I remember them. Density and random-access were indeed lacking.

What else will change in the mindset of programmers/sysadms when the RAM (heap and stack) and HDD are (again) not distiguishable anymore? Like:
1. "Buffer overflow and starting to execute the JPEG file at addr 1.5 TB"
2. "Hey dude? Where is my C:\ drive?"
3. "Huh? The memory-mapped-files are deprecated?"
4. "memory allocation fails. Please try to delete or achive some of you older files"
5. "I want the process with PIDx backed-up"
6. "Ah... the notion of a smart-file-pointer... the GC deletes the file when no longer referenced".

On another note: Perhaps the "no more swapping" model you speak of would draw less power if it used swapping to help cope with fragmentation? Or, perhaps each allocation unit (page), could be turned on or off individually.

Cost (in terms of energy) to "swap" vs "defragment". Granted, replacing "swapping" with "allocation unit on/off switching may be a solution.

Re:Interesting

[KiloByte]

Anything called "memory", even in humans, is volatile.

For permanence, you'd want "clay tablets" or newer technology of that kind.

Re:Interesting

[KiloByte]

3. So you'd have to copy everything around instead of letting the MMU alias it for you? Not a good idea.
4. It's quite inconceivable to have this without any disk quotas.
6. Any OS other than DOS/Windows had that since basically forever. You can even create the file in a deleted state.

Re:Interesting

[GameboyRMH]

What else will change in the mindset of programmers/sysadms when the RAM (heap and stack) and HDD are (again) not distiguishable anymore? Like:
1. "Buffer overflow and starting to execute the JPEG file at addr 1.5 TB"
2. "Hey dude? Where is my C:\ drive?"
3. "Huh? The memory-mapped-files are deprecated?"
4. "memory allocation fails. Please try to delete or achive some of you older files"
5. "I want the process with PIDx backed-up"
6. "Ah... the notion of a smart-file-pointer... the GC deletes the file when no longer referenced".

I hope you're joking. Just partition the RAM separately and it's no different to any current computer with separate RAM. Early PalmOS devices had the RAM and storage on the same storage device (they stored the OS in ROM and loaded it into RAM once the battery was installed...pulling the battery would wipe the device).

Oops, I knew I did something wrong...

[Mr Z]

The memory breakthrough was working on had the speed of flash and the volatility of DRAM. It was pretty dense though...

Re:Oops, I knew I did something wrong...

[Mr Z]

Memory breakthrough *I* was working on... Ah well... back to the drawing board.

Re:Oops, I knew I did something wrong...

[jiteo]

I forgot the memory breakthrough I was working on...

Dupe

[Anonymous Coward]

Isn't this a dupe? I thought I saw it last week.

Actually, don't I see this same article _every_ week?

Re:Dupe

[c0lo]

Isn't this a dupe? I thought I saw it last week.

Actually, don't I see this same article _every_ week?

Nope... must be that your memory got corrupted... cosmic radiation I guess (I might be wrong, though... what if somebody rebooted me meantime?)

usb is high on cpu io

[Joe The Dragon]

usb is high on cpu io there are much better buses to use.

Re:The usual nonsense...

[dgatwood]

- Background storage, even FLASH, is far larger than main memory for a reason

I don't think the intent is to replace main memory, though. The benefits to two-tier storage like this is actually quite significant. A sizable percentage of disk writes don't ever get flushed to disk because they are temporary files.

Combine a smart OS that uses the first tier for write caching and the second tier for permanent storage, you'd be able to significantly reduce wear (assuming, of course, that there is a wear problem with these things as there is with flash parts). Assuming you use a smart controller to flush recent dirty bits to disk if the power gets cut before the OS shuts down the disk correctly, beyond the obvious changes in disk caching, it wouldn't require significant OS changes to use these parts like that, and it would be quite useful, both in terms of disk performance, reliability, and data integrity.

Re:NCSU

[Mitchell314]

:D (NC State student here)

Re:HP

[afidel]

Coming in 2013 according to this article from last year.

Cost/Byte?

[artor3]

Where does it get the power for the non-volatile write? It would have to have a battery or capacitor built in, in case of sudden loss of power. It would also need low voltage detection for the same reason. How does all of this end up affecting the cost and density? We already have non-volatile SRAM based on the same principles (warning: article sounds like it was lifted from a press release).

The reason we use DRAM as computer memory is because it's really, really cheap. If nvDRAM ends up having a significantly highly cost per byte, I doubt it'll see much use. Especially when one considers the ever-falling price point for solid-state drives.

Re:Cost/Byte?

[fbartho]

From what I understood from other comments (didn't RTFA) the point of this is more, it acts like RAM continuously until say you shut the lid of the laptop, then the laptop pulses a bit of extra power and flash[pun] freezes the RAM into a stable state. Bam instant hibernate!

Re:Cost/Byte?

[Stripsurge]

Good question on the cost. Can anybody speak to the ratio between production and material costs in any memory type? I'm curious how big of an impact using exotic materials such as paladium and hafnium will make to the overal cost.

Hmm.. Looking at all the layers they used to produce their chip makes me think that the production costs will be high too.

Re:Cost/Byte?

[Anonymous Coward]

It "saves" on command, when the chip is also supplied with Vpp. Each DRAM cell has "shadow" Flash cell to which it is directly connected ... in fact, those cells are one single structure with two capacitors, one leaky for DRAM, one better isolated for Flash.
It doesn't have to have a backup battery or capacitor built in, non-volatile SRAMs don't have them either, at least not on chip die, they are usually just sealed together in molded package for convenience. However, non-volatile "CMOS" configuration parameter RAM on your computer's motherboard is probably backed by coin cell battery on the board, not in the package.

Addition of non-volatility to this new type of memory would be similar to the one done on SRAM: after the power failure is detected, memory power would be switched over to external battery (or, in this case more likely a cheaper capacitor), which would supply power for issuing "save" command, then non-volatile controller chip would disconnect battery as well (in case of non-volatile SRAMs battery must remain connected to prevent erasure of SRAM contents).

mv UNIVERSAL_MEMORY NESTED_MEMORY

[Anonymous Coward]

Let's just call it nested memory. kthx.

say goodbye to volatility! or?

[moxsam]

So it's time to think about the next step: overwrite before freeing memory.

I don't worry at all, it becomes a software problem, not a hardware problem. If only everyone overwrote unused memory...

Re:say goodbye to volatility! or?

[GameboyRMH]

It could be useful as a hardware feature. The same way a powered-down hard drive parks it's head, a chip on your mobo could zero-over your RAM using power from a capacitor if the power cuts out.

But...

[Rudd-O]

...does it run Linux?  ;-D

Re:But...

[maxwell demon]

No. But it might store it.

Finally!

[Max Littlemore]

Whatever year it it comes to market, you can be sure of one thing....
That will be the year of Multics on the desktop.

Re:Finally!

[Misagon]

Don't dis Multics! Multics was forward-thinking, but perhaps too much so for its own good. Unix got the upper hand much because it ran on cheaper hardware that did not have have an MMU.
If someone is planning on creating an OS from scratch to run on mobile or embedded devices, then I think that that person should take a look at Multics first instead of creating yet another Unix copy.

Re:Finally!

[Max Littlemore]

I agree totally. I was only half fishing for +5 Funny. Absolutely no disrespect meant. I seriously think that high speed non-volatile memory is the only stumbling block to making multics really useful.

Was hoping to get at least one Insightful for my comment, but instead I get a bunch of Funnys and some neck-beard behaving like I just shot all his chickens.....

Re:The usual nonsense...

[sjames]

Background storage, even FLASH, is far larger than main memory for a reason

That reason is that main memory is more expensive, is volatile, and requires power at all times. If that's no longer true, perhaps it's time to revisit the older designs where the storage and the memory were the same thing.

OSses are not designed with this type memory in mind

And they don't have to be if the BIOS zeros it on boot. However, there are substantial advantages to be had if they DO take advantage. For example the suspend states become much simpler.

At the same time, there are OSes that ARE designed this way. Currently, they use disk backed memory, but would be quite happy to just commit RAM to the flash.

- Have you wever counted how often you need to reboot a computer? WTF is this thing going to help?

See comment on simplified suspend state.

It's not cycle tested yet, but there is good reason to believe it will have a longer life than flash.

I don't see the density problem, flash seems to do OK now at that density.

It looks like the write to non-volatile should be lower energy than flash.

It's not a product in production yet and it may or may not work out, but it's not quite as dismal as you make it out to be.

meh...

[White Flame]

I think memristors sound a lot more usable than this setup.

Given the other thoughts about heap fragmentation and such things, I don't know if it's reasonable to expect fine-grained "flush to NV and stop refreshing" application, but rather as a system-sleep sort of mechanism. Of course, if memory allocators and GCs are written in knowledge of keeping LRU data clumped together, it might be reasonable. The comments say flushing is done on a "line by line" basis, which I don't personally know how big or small that gets.

One wonders exactly how much juice it takes to flush to NV, vs the standard draw of the DRAM-style mode of operation.

Re:FIRST

[YoshiDan]

Err... Current computers DO have internal USB connectors. Most motherboards have several USB headers for connecting to external ports, these have 2 ports each. You can connect usb devices internally directly to them (obviously with a modified cable/simple adapter).

Re:FIRST

[YoshiDan]

I also forgot to add that I've seen USB interface cards with actual internal ports on them. And my old G4 Mac had internal firewire ports.

"Drastically reduce" the 1W

[koinu]

Maybe in mobile sector 1W per SDRAM module is interesting, but on desktop computers it isn't. They should reduce the energy to keep ATX boxes switched off(!) to 0W, as it was with AT, where a mechanical switch was used to cut the PC from power. It is simply inacceptable to consume energy (usually over 5W) when something is completely down (yeah I know, there is wake-on-LAN etc, but 99% of people don't use it). That's why I have a big fat red switch on my multi-outlet power strip.

Re:"Drastically reduce" the 1W

[DamonHD]

My entire primary server uses less than 5W when operating except when absolutely flat-out when it eats a whole 7W, so I agree with you!

http://www.theregister.co.uk/2010/11/11/diy_zero_energy_home_server/

Rgds

Damon

Re:"Drastically reduce" the 1W

[fruey]

Very nice low power setup. Running complex stuff too. The Sheeva plug looks a good candidate for a NAS / media server without the pain of big optimisation, and would save me $$$ compared to running PC tower configs to mostly copy files to my box under the TV.

About time...

[Tasha26]

The memory market place was too much drama (teehee) in the end. At least now we can hope for some economies of scale, which will hopefully be passed on to consumers.

Impressive stuff, but...

[dmomo]

What does this mean to users? There's no new functionality. It's more or less "combined" existing functionality.
So, what is the significance here (I'm honestly asking, I'm sure there is some interesting consumer benefits).

A few I can think of:
1) Longer battery life on mobile devices
2) Instant "on", since the state of the OS and applications can remain in memory

With #2 I would guess that certain programs that maintain clock pulse counters may operate "oddly" and have to be reprogrammed to stay in sync. Though, I'm sure there would be some kind of "memory going to / returning from virtual back burner" interrupt.

Another implication I can think of is user security. Shutting down the computer may not be enough in the same manner that "emptying your recycling bin" does not physically remove the data. Hopefully this memory / flash is easy to wipe, and it would probably be partitioned into "working / ram memory" and "storage".

Re:Impressive stuff, but...

[cyclomedia]

Actually 2) has interesting connotations. Those of us old enough to remember the 80's will remember when Memory Mapped IO was the norm. This meant that the CPU treated all data as an extension of RAM. Your memory sticks, hard drive, floppy disk and network card buffers etc could all be mapped onto the CPU's memory space. Each had different speeds (obviously) and the total memory could not exceed the addressable space of the CPU (e.g. 4GB, but there were tricks for getting around this). To get something into RAM you'd copy the bits from one memory address (that's mapped to a drive) to another (mapped to a RAM stick).

x86 has IO mapped IO. RAM and where-the-data-comes-from are treated differently, you have to tell it that data is coming from an IO device and to pipe it through and the concept of "this bit over here is RAM that you can toy with using memset and all that" is hardwired to be different from "this is a drive and you have to talk to it like this".

Back to the topic at hand. SDRAM speed Non volatile storage could not only replace your RAM it could also replace your hard drive. An application "on disk" would no longer need to be "loaded into RAM" to be executed or accessed by the CPU. That is, if the "disk" was memory-mapped : the CPU would just be able to find it and execute it on the spot. No lag whatsoever.

Re:Impressive stuff, but...

[badkarmadayaccount]

Execute in place is kinda old, BTW.

Re:The usual nonsense...

[Eivind]

If - but that seems a pretty gigantic if to me.

It's *very* common with speed/price/size tradeoffs in engineering, regardless of which technology choosen. Usually, "pick any 2" is what it boils down to.

Sure, in principle, if you invent something that scores well on all 3 axes, then no trade-off is nessecary and all the older systems that score poorly on atleast one of the 3 axis, are obsolete. But I'm not holding my breath.

For storing large amounts of data for a long time, you want huge and cheap, but need little speed. For the registers in your CPU, the opposite is the case, you want all the speed you can possibly get, yet the amount of storage is very limited.

Re:The usual nonsense...

[sjames]

As you say, it's a trade off. If it's strong enough on 2 axis and not so bad on the other, it might be enough, at least for some application. After all, the pick 2 rule applies to everything we use now as well.

We already have a trend to using flash as storage (it's all the rage!), so it's not exactly a huge leap to imagine this catching on if it's decently priced and really is more durable.

Not the universal memory

[maxwell demon]

The universal memory would have the speed of SRAM, the density of Flash, would write directly into the non-volatile memory (i.e. no extra nonvolatile storage step, and certainly no need to refresh), and would have the same price per bit as hard disks. That way you could it use in cache (SRAM speed), as DRAM replacement (beats DRAM in any category) and as hard disk replacement (nonvolatile, cheap).

This "universal" memory would be unsuitable for cache memory, thus it isn't universal.

Re:FIRST

[somersault]

Why you would actually want to use USB rather than SATA or eSATA is beyond me though. Maybe USB3 in the short term.

Re:FIRST

[marcosdumay]

You still don't want to plug your core memory into a hight latency DMA controlled bus.

Re:FIRST

[GameboyRMH]

SATA is better than USB for internal drives, but eSATA can be a PITA to set up - do Average Joes even know how to do all that crap in the BIOS to get it working in the first place, never mind having to hook up a separate power connector?

Re:The usual nonsense...

[GameboyRMH]

- Background storage, even FLASH, is far larger than main memory for a reason

What does this have to do with anything?

OSses are not designed with this type memory in mind

The only possible problem any current OS could have with this is this:

Have you wever counted how often you need to reboot a computer? WTF is this thing going to help?

...which could easily be solved by a BIOS tweak. Empty RAM on powerup. Problem solved.

Density will be far lower than DRAM, causing significantly higher prices and preventing it from competing. Also more complex cells are inherently more expensive and less reliable

Yeah that's why we're all still using EEPROMs and 5 1/4 floppies. Those hard drives the size of microwave ovens are just too damn expensive.

An "emergency flash write" still takes a lot of time and energy, at least partially invalidating the concept

And how often do you do anything like this with current storage technologies?

...and requiring another daemon

[whitroth]

One to utterly wipe RAM... No, encrypting RAM is not an alternative, unless you really enjoy having your system, with the power of a supercomputer of 15 years ago, move with the speed of a *whizbang* 8088....

                mark

It's no use, no one listens to ACs.

[Anonymous Coward]

Especially not the technically competent ones.

Re:FIRST

[AaronW]

I've never had a problem and haven't had to touch the BIOS for eSATA. I just plug the drive in and it works. Then again, I'm running Linux.

-Aaron

Re:FIRST

[GameboyRMH]

Same here, but most mobos aren't configured to support eSATA out of the box in my experience.

Re:FIRST

[YoshiDan]

I wouldn't. I was just saying that computers usually do have internal USB ports of a kind if you need to connect devices internally. I imagine it could be useful for things like copy protection dongles and things like that that you wouldn't want to be stolen from an office computer.

In regards to eSATA: I prefer it over USB, as any sane person would; but I have encountered a few problems regarding hot swapping in the past

Re:FIRST

[somersault]

I was meaning "why you would actually want" as in a colloquial form of "why anybody would actually want", maybe I should be more explicit though..

Re:Early DRAM (refresh is sometimes easy)

[Douglas Goodall]

I was reading the technical specs on the Z80 recently, and the Zilog designers were brilliant in their CPU design which automatically refreshed the dynamic ram by using a self incrementing "R" register to traverse enough addresses to do the full refresh. That was back in the late 70's and 80's, and that more or less the same dynamic ram is with us still. We could use some advances in that area. It seems like we are struggling to find the elegant memory solution. When I started with computers, we were writing into a core to sense it's state then having to write the information back. That was clever, but inefficient. Now we have dynamic memory that wants to go to sleep, and we have to nudge it regularly to keep it awake. I hope in my lifetime we finally see a memory technology that is actually straightforward and elegant.

Re: PRAM Memory

[Douglas Goodall]

We could call it prescient memory, and it could recall data from the future as well as the past. You wouldn't even have to write the data into it, or give it the address of the data you want because it knows what you want before you ask.

Been there done that...

[Reverand Dave]

I worked at a memory company who's name rhymes with Licron for over 10 years and about 8 years ago we were working on something similar to this. It was basically high speed NOR flash memory, but the project didn't get much traction in lieu of ramping up on DDRDRAM and Rambus DRAM memory production. Given the fact that DRAM production is an almost completely money losing venture you'd think memory companies like Infineon, Hynix, and Samsung would be pushing this technology a bit more aggressively.

Say hello to the memory hole

[eightball]

I didn't know they axed duplicates now..

"Memory On Demand" Cuts Energy Use
Posted by CmdrTaco on Wednesday January 26, @09:00AM
from the cut-it-off dept.
judgecorp writes
"Researchers are testing memory that can be powered down when not in use. This could slash the power used by computer memory, combining the benefits of DRAM (speed) and Flash (low power, non-volatile). The memory could also allow "instant-on" computers, according to an IEEE Computer Society report of the research at Carolina State University."
Read More

http://it.slashdot.org/story/11/01/26/1342246/Memory-On-Demand-Cuts-Energy-Use