Re: I Should Surrender to Opteron

mike wrote:
Years ago there was a flurry of interest in so-called "wafer scale integration" where CPU plus memory and everything else in the system would be laid out across a whole wafer.

The high defect rate that comes from expanding logic over larger areas killed the idea. I wonder if modern error detection and recovery techniques along with technology like IBM's "chip kill" and redundant components can resurrect the idea.

Imagine a single 12 inch wafer as an alternative to the printed circuit board in a "blade" like system. Each wafer would have 4, 8, or 16 CPU's along with several spares so that after testing a minimum specified number of working CPU's could be guaranteed. The same wafer would have the equivalent of several GB's of RAM also configured with spares and error detection / correction.

In this scenario, all CPU to memory communications would be "on chip" or at least a lot faster than today's off chip speeds. Further, it would be practical to increase the number of memory banks and the width of CPU to memory busses far beyond what is practical with current packaging.

Certainly costs would be far higher than just building an equivalent number of CPU as stand-alone components. However, I wonder how wafer cost would compare with full system costs especially considering potential performance improvements. Even if it is too expensive as a replacement of commodity parts, would it be a reasonable for Cray or IBM's Blue Gene or someone else in the high performance market?

Mike Sicilian








"David Wang" <foo@xxxxxxxxxxx> wrote in message news:dvnn36$p13$1@xxxxxxxxxxxxxxxxxxxxxxxx

Iain McClatchie <iain-3@xxxxxxxxxxxxxxxx> wrote:

David> Not that there isn't a market for this sort of thing [eDram],
but that market
David> is very very far away from the commodity market.

It's as far away as the nearest Xbox 360, which has a 10MB eDRAM die
stuck on the same package as the GPU. The eDRAM die takes care of
the frame buffer and various antialiasing operations done within it.
Apparently they manage to make good use of the very wide interface
to the on-die eDRAM.

Graphic folks that I've talked with say they keep looking at eDRAM, and
it's always on the edge of being a good idea. I've heard it gets a
fair bit of use in mobile graphics parts.

Right. I should've been more specific.

It sounded like John was trying to "surrender" to Opteron for some sort
of HPC work, so he's looking for general purpose CPU's with "good enough"
FP performance and "good enough" memory system.

I don't see eDRAM coming into the general purpose CPU side of things,
because 10's of MB was never going to be big enough for a modern OS and
some applications. So John won't get a chance to "surrender" to a general
purpose, commodity CPU with ten's or hundreds of MB of eDRAM any time
soon (IMHO). The graphics stuff, certainly. Now, if they start to allow
reconfigurablity to the point of being able to do DP FP on them, they
could become interesting for HPC sort of things.

OTOH, I am a fan of die stacking. Getting multiple GB of memory with
GB/s of bandwidth at near commodity prices sounds very good to me.


--
davewang202(at)yahoo(dot)com



Driving multiple centimeters on wafer is harder than doing so on ceramic. And if you want a lot more wires they will be quite resistive.

del

--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions, strategies or opinions.”
.

Relevant Pages

  • Re: I Should Surrender to Opteron
    ... integration" where CPU plus memory and everything else in the system ... techniques along with technology like IBM's "chip kill" and redundant ... Imagine a single 12 inch wafer as an alternative to the printed circuit ...
    (comp.arch)
  • Re: I Should Surrender to Opteron
    ... Imagine a single 12 inch wafer as an alternative to the printed ... all CPU to memory communications would be "on chip" ...
    (comp.arch)
  • Re: I Should Surrender to Opteron
    ... Years ago there was a flurry of interest in so-called "wafer scale ... all CPU to memory communications would be "on chip" or at ... to the on-die eDRAM. ...
    (comp.arch)
  • [PATCH] Document Linuxs memory barriers [try #3]
    ... The attached patch documents the Linux kernel's memory barriers. ... I've tried to get rid of the concept of memory accesses appearing on the bus; ... barring implicit enforcement by the CPU. ...
    (Linux-Kernel)
  • Re: read vs. mmap (or io vs. page faults)
    ... not fit in main memory, and there are overheads related to the heuristics ... But because the CPU is underutilized, ... reasonably sized user buffer). ... You have to measure the actual overhead to see what the actual cost is. ...
    (freebsd-questions)