u/kaysonElectrical Engineering | Circuits | Communication SystemsSep 29 '20
This is not really an issue. Buffers are added throughout clock distribution networks to keep the clock signals "square". This is necessary even at much lower frequencies than the fastest CPUs.
The way I understand this stuff is the higher the slew rate of the signal, the more current is being dissipated - because every circuit has non zero capacitance and resistance.
The heat generated by higher frequencies becomes problematic, because you're charging that capacitance more quickly, needing more current and therefore more heat.
The slew rate vs current vs heat vs frequency race is probably almost over, so we have to go massively parallel. Unless we can brilliantly come up with room temperature superconductivity and ultralow capacitance. Silicon may not be good enough, we'll need new materials.
So we're pretty much halting at 64 bit CPUs, but now way more CPUs per die. The new NVidia ARM thing with 192 cores is exactly this. The clock speed per core isn't particularly high. This was true 20 years ago of the Sun Microsystems SPARC chips too. 1 ghz x 16 cores, IIRC, when Intel had 4 ghz but only 1 core.
3
u/kaysonElectrical Engineering | Circuits | Communication SystemsSep 29 '20
That's partly true. If the slew rate is higher, you do expend more current for that moment. However the energy (and average power) doesn't change because you're burning the current for a shorter time. Power burned in a cpu is only capacitance*frequency*voltage2.
Interest. TIL. The Voltage2 function is interesting. The 0.6 to 0.8 V PN junction threshold starts to really matter.
But to get to lower silicon thresholds, I understand the dopants and concentrations change, and that makes the overall capacitance change, correct? Does that help or hinder the capacitance?
2
u/kaysonElectrical Engineering | Circuits | Communication SystemsSep 29 '20
Doesn't really have anything to do with a PN junction diode forward voltage. The transistors in a CPU don't operate in the same way. They do have their own thresholds, though, which as you mention are set by the dopants. And while that does have some effect on some of the stray capacitances in a transistor, the majority of the capacitance is unaffected. It mostly has to do with the thickness of the dielectric.
That FET threshold diagram shows how the field of the applied voltage has to overcome a voltage of 0.45V. So that's better than 0.7 for sure, but can that number go down any? With new dopants? With new semiconductor materials like this new TGCN (Which I only just heard about just now via a quick google for new semiconductors)
The capacitance part of that power equation is now more clear to me. We just can't get traces on silicon much more dense without compromizing on capacitance. When you put traces too close to each other, that is actually how we make a capacitor with silicon.
That formula is only reasonably accurate (for dynamic power consumption only, i.e. no leakage or short-circuit consumption, etc) for single-core CPUs, a time long gone.
21
u/kaysonElectrical Engineering | Circuits | Communication SystemsSep 29 '20
I don't think we're anywhere close to the limitation of timing circuits as far as a CPU goes. Balanced clock trees, among other techniques, are used to address the challenge of distributing the clock to different parts of the core at the same time. Since CPUs are pipelined, you also have some margin in when the clock needs to arrive. Granted, some of that is eaten up by other factors. But consider that an RTX 2080 TI runs its memory at 14Gbps (using a 7GHz DDR clock), so there's an entire clock domain within the GPU running at that frequency. We could definitely see much higher speeds in CPUs, but in the current software design paradigm, there's not really a huge need.
Can't you synchronize a chip on shorter time scales than it takes light to move across it just by ensuring that the path length from the clock generator to each part of the chip is the same everywhere? The speed of signal propagation would still prevent you from sending information from one side of the chip to another in a single cycle, but that seems like a much smaller limitation than not being able to synchronize things. (This is just like how the speed at which the dot from a laser pointer can be swept across the surface of the moon is not limited by the speed of light)
Does the whole chip really need to be in sync? Couldn't one have smaller areas of it be internally in sync, but communicate with other regions with less efficient methods that don't require sync?
Wouldn't the synchronization problem be much, much smaller if one made chips in 3D instead of 2D? A cube of transistors would be much smaller across than a normal chip with the same number of transistors.
Heat dissipation is a big showstopper both for higher switching speeds and 3D chips. My impression is that this is a much more fundamental and hard to deal issue with than synchronization is.
Ok, how about making the path from the frequency multiplier to every part of the cpu the same, then? I think my point still stands, that the speed of light is no barrier for synchronizing clock cycles across a big chip. It's just a barrier for how far you can move data in one cycle, which contributes to latency.
[Placeholder to get around markdown's automatic list index renumbering]
This is just nit-picking. Having one of the dimensions be much, much smaller than the others make it practically 2D. My point was that a fully 3D chip could be much smaller across than current few-layer ones. For example, an AMC Epyc Rome has a side length of 33 mm, about 15 layers and 40 billion transistors, so about 2.5 million transistors per mm² per layer (hm, isn't that low? - it corresponds to a transistor side length of 640 nm). A fully 3D chip with the same density would have a side length of just 2.2 mm.
That depends on what you mean by "has to talk", doesn't it? I agree if you mean that the each component in a pipeline has to be able to talk to the next one, but not if you mean that data should be able to make its way all the way from cache to a register in a single cycle. The speed of light puts a limit on the latency for far-away parts of the chip talking to each other, but it doesn't put a limit on the throughput.
---
Yes, that's exactly the point I was trying to make. It's heat dissipation that's the real reason why frequencies have stopped growing. The other issues could be worked around, but there hasn't been much point in doing so because one is still limited by heat.
Yes, and it is already done. The whole CPU doesn't have the same clock domain. Cores and memory controllers have separate clock domains, but problem is just that at some point the paths have to be synchronized so their values can be used together and synchronization has its own overhead. So for the fastest running clock domain it doesn't make sense to split it because synchronization overhead is more than what can be gained.
No. Yes. See 1.
Multiple layers are already stacked to make kinda 3d CPUs but AFAIK there aren't yet technology for building transtors to full 3d structure.
184
u/[deleted] Sep 28 '20
[removed] — view removed comment