so what are the complications involving the embedded dram?

[pen^2]

everyone (yes, including the bitboys oye) keeps on talking aobut how embedded ram could solve all the memory bandwidth limitation with the current generation 3d cards... so i am assuming there is a good reason for not being able to see a single product with it yet? cost? technology? just curious...

 

[pm]

Cost mostly. There are a few technological problems too, but it's mostly cost. I don't know that much about the specifics, but I know that DRAM and CPUs (and GPUs and chipsets) are made with processes that have more than few differences. There are more initial process steps for DRAM to create trench capacitors and the to get the cell cap up as high as possible, and there are far more later process steps for CPUs since DRAM wiring usually is only 2 metal layer and CPU processes are up to 6 metal layers. So when merging these two processes you end up with yield issues, mask costs, fab costs and at the end there not that big a performance advantage over a CPU with a lot of cache (which uses CMOS SRAM rather than capacitance-based DRAM).

IIRC, ATI released a GPU with embedded DRAM. It didn't do very well in the market and they later replaced with a conventional design.

All the experts seem to keep saying that embedded DRAM is the future, but I don't see any product announcements. I don't think we will see any major products based on embedded DRAM in the next two years.

 

[superbaby]

From what I have read it's more about the complexity of integrating the DRAM with the chip. Apparently it complicates the chip so much that it becomes nearly impossible to work with. What pm said about the fabrication process is true as well.

I always thought EDRAM had to be implemented like pointers in C... but here you have to make the chip point to the correct memory addresses.

 

[pm]

<< From what I have read it's more about the complexity of integrating the DRAM with the chip. Apparently it complicates the chip so much that it becomes nearly impossible to work with. >>



Chips are absolutely unbelieveably complex already. Teams of 100-300 engineers work 2-5 years full time on designs involving 10's of millions of transistors. I can't imagine that the problem in complexity - at the minimum you could do what some L2 SDRAM cache designs do and completely partition the problem. The core is one design, the embedded DRAM block another and then just integrate them at a few select design points. So you separate the problem into two separate problems altogether.

But I don't think that this is necessary. DRAM is an array, you design one bank together and you don't really need to worry about the rest. It's like SDRAM caches. A way is a complete design - beyond that point, you just tile up ways to make a cache array. The pain of doing this is pushed out to the decoder and control logic, but still that's no more complex that a standard design at the bank level... and the more complex decoder logic can just be synthesized and autorouted.



<< I always thought EDRAM had to be implemented like pointers in C... but here you have to make the chip point to the correct memory addresses. >>



You should be able to do it so that it is completely invisible to the end-user. It should be seamlessly integratable. I can't imagine that anyone would attempt this if it required a recompile - in the x86 world, recompiles are generally frowned upon (to put it mildly). If I were designing such a beast, I would probably either attempt to put so much DRAM on the chip that the system doesn't need to be upgraded (ie. try for >=64MB) or, if this wasn't possible due to reticile (sp?) considerations, then I'd use the DRAM to implement a mammoth cache (like 16MB, for example).