8 ms·
Imagine 32GB of this V-Cache instead of RAM. Does each additional layer add latency? If so, I wonder how many layers you could have until it would reach RAM-equ
by runeks 5y ago
Imagine 32GB of this V-Cache instead of RAM. Does each additional layer add latency? If so, I wonder how many layers you could have until it would reach RAM-equivalent latencies. Also, it would require a compiler change if you had 500 sections of RAM (at 64MB per section) with latency increases for each section.
- Cthulhu_ 5y agoI'm confident we'll see memory-on-chip within the next few years. Actually isn't that already the case for mobile CPU's?
- baybal2 5y agoMain memory, if you mean DRAM, no. DRAM is incompatible with the logic family used in CPU making, though attempts were numerous at trying to work around that. Every few years, there are somebody coming with claims of passable CMOS+DRAM tech, but none got adoption so far.
- my123 5y agoIt is not actually incompatible within the same die, IBM z15 uses eDRAM for the L1 caches even.
- baybal2 5y agoNot L1, but L2 and on. A very curious case, and a very clever hackery with a custom SOI process. It's still very, very far from coming to mainstream chips.
- jahnu 5y agoIt says L1 here "Both it and all levels of cache in the main processor from level 1 use eDRAM, instead of the traditionally used SRAM." https://en.m.wikipedia.org/wiki/IBM_z15_(microprocessor) https://en.m.wikipedia.org/wiki/IBM_z15_(microprocessor)
- baybal2 5y agoI got L1 being SRAM from here https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edram-density-adds-hundreds-of-megabytes-of-cache/ https://fuse.wikichip.org/news/3383/ibm-doubles-its-14nm-edr...
- amelius 5y agoWhat is the main hurdle? Why are these processes incompatible?
- geertj 5y agoGenuinely curious, could you say why logic and dram on the same chip are incompatible?
- adwn 5y agoThat's because high-density logic and high-density DRAM require very different steps during wafer fabrication.
- baybal2 5y agoFor practical considerations, both DRAM, and CMOS need a lot of steps, and both of them are already dialled closed to thermal limits of materials. So if you just first make CMOS, and leave empty space nearby protected by something to do DRAM later, it will be very hard to fit into the tiny remaining thermal budget past which CMOS devices will turn into schmoo.
- colejohnson66 5y agoBasically, at the low nanometer range,[a] if you want on-chip DRAM, it’d be a separate die (“chiplet”) connected by the substrate [a]: what’s the upper limit? As in, when does it not work anymore? For example, would it work at 100+ nm?
- baybal2 5y agoI am not a specialist, but I think I can guess. First, you need a wafer on which you can make a capacitor, which already means an SOI process, and SOI wafers. The lowest nodes with SOI available to mortals are 40nm, and 14nm on GlobalFoundries, but god knows how one gets GloFo to collaborate on that. Then, you need CMOS device which has enough thermal budget to survive both own, and DRAM creation. Third, I think on-die DRAM will only make sense when it wins over SRAM. DRAM cells cannot physically go smaller than the minimal size of a trench capacitor. I believe at 5-7nm nodes, 6T SRAM will already be smaller than a reasonably fast eDRAM per area. We know that IBM's Z15 is a 14nm FinFet chip, and it has DRAM on board, with them probably somehow doing DRAM first.
- MayeulC 5y agoI work on ferroelectric hafnium, which looks promising with regards to CMOS compatibility. It's non-volatile, though I guess you could also use it like DRAM. Endurance is an issue for now though (it's approaching RAM use-cases, but not SRAM yet). As you said, I'm not sure about the density part. Unless it's completely done in BEOL, I don't see designers trade precious chip real estate for memory (unless pin or power-limited, of course).
- baybal2 5y agoHafnium? Is it something FRAM related? What do you think on FRAM vs. next generation MRAM?
- MayeulC 5y agoI don't know much about STT-MRAM, so I'll avoid making a fool of myself. Looking more into the details is on my TODO. Look at the datasheets and make your choice, as usual. I am not sure how the situation will evolve on either side, my understanding is that FRAM could be more energy-efficient. Well, hafnium can be used to make ferroelectric crystals, that are necessary for ferroelectric memories (FRAM). The most used ferroelectric material is PZT, which has lead, and is a nightmare for CMOS compatibility due to contamination issues, and temperatures. It's a bit light on the details, but maybe I should point you towards the video that explains our project: https://www.youtube.com/watch?v=M8tL-nN7G-A https://www.youtube.com/watch?v=M8tL-nN7G-A The most exciting part might not be the performance (though it looks good), but the way ferroelectrics can be used for new circuits (variable treshold transistors thanks to FeFETs). Hafnium has been used in gate oxides for a few years now so it's quite compatible with CMOS.
- ksec 5y ago>https://www.tomshardware.com/news/innovative-type-of-memory-promises-higher-capacity-and-performance https://www.tomshardware.com/news/innovative-type-of-memory-... No word on latency though.
- simias 5y agoYou can find stacked chips pretty commonly, but it's effectively two chips within a single package.
- kllrnohj 5y ago> I'm confident we'll see memory-on-chip within the next few years. Depending on what you mean by "memory-on-chip" we've already seen this with AMD's Fiji (2015) & Vega (2017) line of GPUs which used on-package memory in the form of HBM/HBM2 memory ( https://www.anandtech.com/show/9390/the-amd-radeon-r9-fury-x-review/3 https://www.anandtech.com/show/9390/the-amd-radeon-r9-fury-x... and https://www.anandtech.com/show/11717/the-amd-radeon-rx-vega-64-and-56-review/2 https://www.anandtech.com/show/11717/the-amd-radeon-rx-vega-... ). It was incredibly fast, but also very expensive and limiting in SKU configurations. The resulting 16GB SKU for the Vega 56/64, for example, made basically nobody happy. It was too much for gamers, who then didn't want to pay money for something that didn't help, and it wasn't enough for the professional crowd, who were getting used to 24GB offerings from Nvidia. > Actually isn't that already the case for mobile CPU's? Nope. They "just" replace the slot with solder more or less. It's still externally packaged DRAM modules.
- Sparkyte 5y agoActually already a thing but production of the memory isn't easy so not as cost effective yet. HBM is used on the VEGA graphics. GPUs are a type of processor.
- klodolph 5y agoWhy are you confident about this? Semiconductor processes are complicated for a ton of reasons, and a process which is optimized for making main memory (DRAM) has some differences from a process optimized for making logic (CPU), and flash memory is different still. I see AMD's effort as a way to sidestep the whole problem of putting memory and CPU on the same chip, by making separate chips and stacking them. It makes sense. You can get CPU packages with CPU + DRAM + Flash, but these are separate chips which are wired together inside the package. E.g. https://en.wikipedia.org/wiki/Package_on_a_package https://en.wikipedia.org/wiki/Package_on_a_package The whole point of these systems is to avoid putting memory and CPU (and flash) on the same chip. AMD's version is smaller & more integrated than package-on-package but it still achieves the same goal: multiple chips.
- mehrdada 5y agoMobile SoCs like A14 have a Package-on-Package architecture with DRAM die stacked on top of CPU, but it is not the same die.
- xondono 5y agoIn short, yes, higher capacity will involve higher latency. The thing here is balancing core speed vs “effective” memory latency (factoring in cache hits, misses, etc). Cache management is a hard problem, and the equilibrium point is load dependent (i.e. depends on what type of program you use). AMD has been smart enough to understand that sometimes it’s better to just brute force your way in (with higher cache sizes) than being super clever about how you handle it.
- hajile 5y agoAMD's SenseMI is a neural network to predict data fetching. That's quite the opposite of brute force. They add massive caches as a side effect of having loads of cores enabled by their chipset designs.
- wallacoloo 5y agoDepends on your definition of “brute force”, I guess. Between explicitly deriving some algorithm from an understanding of causal relationships, v.s. training a neural net on billions of samples without encoding any broader understanding of the world, the latter approach is the one I would have called “brute force”.
- xondono 5y agoUsing NN for cache management is not that new, and is a simpler approach in comparison to Intels as far as I know.
- IgorPartola 5y agoAt 192MB, just give me explicit access to this cache as memory and I’ll decide what goes into it. No need to try to predict what my code will want, I can just tell you.
- derefr 5y agoImagine coding for a 64-bit version of the 6502, where you have a 192MB "zero page" :)
- nine_k 5y agoAs I imagine it, I immediately wonder how to cool it.
- amelius 5y agoRAM typically doesn't generate much heat.
- kevincox 5y agoBut IIUC you would at least need to pass the heat of the CPU though the RAM. So if you want to keep a lot of memory near the CPU you are at the very least adding some sort of "blanket" between the heat source and the heat sink.
- nine_k 5y agoAlternatively, you could put the CPU core on top of RAM, closest to the heat sink. You also don't want to run your CPU at 80°C, else the RAM will produce much more errors. (ECC is a must anyway, I suppose.)
- kevincox 5y agoYou can definitely do that, but now your RAM is twice as far away from the CPU on average than if you put RAM on all sides. The best solution is probably some sort of hybrid where you put RAM on all side, but more on the bottom to balance the thermal effects and the latency.
- amelius 5y agoThermal resistance is linear wrt the thickness of the material, so if the layer is sufficiently thin, it doesn't form a significant obstacle.
- rbanffy 5y agoThey also mentioned both dies are thinner so they are mechanically compatible with current heat spreaders.
- Zenst 5y agoWhilst it would be nice, we would be adding a lot more heat into the CPU block. Maybe they could and add extra cooling on the other side, though would really be looking at reinventing the CPU socket and thoughts of Intel Slot-1 form factor start to become appealing again as a form factor to allow such cooling solutions. Now what we have over the years seen interest in is adding processing cores to the RAM itself and maybe having a small dedicated processor for some tasks attached to the RAM may well prove viable. Imagine if we didn't have any CPU or RAM sockets/slots and just a row of slots you addedd a module that had CPU/RAM in one and can just add more upto the slot limit. But then, that is kinda how GPU's have gone already in many aspects and look at how much RAM they hold and how large the cooling solution for them is. That gives you an idea of the cooling needed for large amounts of processing and RAM when closely packaged.
- linuxftw 5y ago> Now what we have over the years seen interest in is adding processing cores to the RAM itself and maybe having a small dedicated processor for some tasks attached to the RAM may well prove viable. I think we call these 'GPUs' today. > just a row of slots you addedd a module that had CPU/RAM As you mentioned, GPUs fit this description, but some PCIe devices are full-blown embedded systems. I think we're at the point where the only major improvements will take place on the CPU die itself.
- derefr 5y agoGPUs aren't quite the same, because they're (mostly) SIMD. GPUs don't have the independent per-compute-core memory bandwidth required for every core to be running its own execution thread with an independent instruction pointer, independent data fetches, and (especially) non-correlated branch-prediction failures / cache misses. (This is most of the reason that branching, if even implemented in the GPU's ISA, is effectively useless.) Whereas, what the parent poster is describing would be true MIMD: a bunch of tiny cores each with its own on-board RAM, its own instruction pointer, and then a bus (or a bunch of busses) fast enough to feed them all data from (probably NUMA) main memory. GPUs don't provide any advantage for running e.g. a high-concurrency Erlang application server. But a true-MIMD system would.
- swiley 5y agoOn the other hand, 128MB is enough for my entire desktop environment and most of the (non-game) apps I use (obviously not at the same time.)