3 ms·

One thought that isn't on here: Once the process is "mature" and isn't changing every few years, the error rate could be squeezed way down. That would make it

• n00b101 10y ago
  >Make way for the 64-bit 128-core 1024gb RAM 8cm^2 SoC This is already happening? Intel Xeon Knights Landing already has an enormous 6.83cm^2 die size. It has 72 "cores," each of which has a 512-bit vector processor. In some sense, you could say that this chip has 9,216 "single precision cores." It also supports up to 384GB DDR4 RAM, which is not far from your 1024GB. The term "core" is becoming vague, as NVIDIA refers to thousands of "CUDA cores" on its GPUs which are really vector processor elements. China's Sunway SW26010 is also kind of a "SoC," 260 "cores" communicating via a Network-on-Chip interconnect. I think one could say that the Cell Broadband Engine processor had a similar design. > make it practical and economical to make larger chips I do wonder if die sizes can increase. I'm not a hardware engineer, but my understanding is that latency is the main barrier to larger chips. The time it takes for a signal to propagate across a chip limits the clock frequency. One possibility is to replace the global synchronous clock design with an asynchronous chip design. However, from what I understand, this would make things worse because some form of synchronization is always needed - you could send back an "acknolwedge" message, but that would double the signal traffic. On the other hand, supercomputers are regularly built with multi-socket systems and interconnects like QPI and PCIe between processors and nodes. It would seem logical to put multiple processors their interconnects on a single "SoC" and I don't know why that doesn't happen. Maybe it is because of error rates, as you say.
  • pjc50 10y ago
    Asynchronous does not help you on latency at all - it's not the latency of the clock that matters. It's the data latency. This is already kind of crippling, as it takes hundreds of cycles to get anything from RAM if it's not in your cache. Only way to improve that is to make programming languages push either data locality or dataflow like designs, which may mean giving up or reimagining OO. Error rates (yield) are a serious problem, but if your design is uniform enough you can very well get away with just disabling bits. There's also a less obvious problem with on-chip variation (OCV) - some physical properties have a gradient across the chip. At runtime, there's a temperature gradient as well.
    • api 10y ago
      Or... continuing with the BFC concept... make chips with monster caches or even with all SRAM running at core speed. That's not been done in a while.
      • pjc50 10y ago
        Caches effectively are SRAM. It's inherently much less dense than DRAM; I had a quick look on Intel and the largest I could see was 37Mb of cache.
        • n00b101 10y ago
          It's not SRAM, but Kights Landing has 16GB of "MCDRAM" which is high bandwidth 3D-stacked DRAM. 400+GB/s throughput but latency is similar to conventional DRAM.
  • deleted 10y ago
    [deleted]
  • Dylan16807 10y ago
    Latency is not a problem. The recent huge chips from Intel serve as a perfectly good example. Haswell puts the cores and IO controllers on 1-2 ring busses. Knights Landing uses a mesh network. In each cycle, data only has to travel between neighboring nodes. A memory controller that's 4 hops away is barely noticeable.
• adwn 10y ago
  It's a lot more practical to put several dies insides one package, which is already happening (for example, the largest FPGAs from Xilinx have 4 dies in a single package). Intra-package communication is not quite as good as intra-die communication (from a performance and energy point of view), but it's a lot better than inter-package communication, and several small dies have a higher yield than one large die.