Why not make p2p RAM?

[Cerb]

With DDR2 looking to have similar speed issues to DDR in the future, but with high-latency FBDIMMs for the servers.

Why don't they make a type of RAM that is point-point within a channel (assuming some speedy serial RAM)? Like you have the first module connecting with the controller, and have another set of pins to communicate with a DIMM behind it, and then the next DIMM behind that, and so on.

CPU<->DIMM1 on link A<->DIMM2 on link B<->DIMM3 on link A<->DIMM4 on link B...

Seems like such a design would mostly get rid of these problems (low speed with many module on a bus, even lower for higher density modules). Would it just be too expensive to make controllers for each module?

 

[uec0]

I think that's roughly how RDRAM worked.

 

[itachi]

cpu<->d1a<->d2b<->d3a<->d4b?
you'd still need x-bits to address all 4 modules.. the only difference between this and what it is today is that requests for blocks in d4b will have to propagate through d1a, d2b, and d3a.. simpler and less time consuming to run a mux/demux to address the 4 modules.. cpu <-> controller[d1a, d2b, d3a, d4b].. and if the cpu is only aware of the first dimm, then there's no way to address the other 3 modules.

 

[harrkev]

If this were to happen, it would also increase latency. The first chip would be fast, but as you get further away, you get slower. So to achieve optimum results, you have to move the most-often-used stuff to the closes chip, which would take time. This would be a royal pain. Current memory moedels assume that a byte is a byte. Cache helps things go fater my making a memory heirarchy, but the operation of cache is completely transparent to the programmer (unless they WANT control to improve performance, which is optional).

This would aslo double the amount of pins on each memory module, and for not much gain.

 

[thelostjs]

seems like what you are suggesting is already the case?

the on die cache functions like what you are suggesting right?