5 ms·

At 100 GHz signals can only propagate 3 cm per clock. So to run at those speeds, you need extremely compact circuits, and you need to bring memory closer too.

At 100 GHz signals can only propagate 3 cm per clock. So to run at those speeds, you need extremely compact circuits, and you need to bring memory closer too. Maybe move to 3D, another way to increase reach. What is the current thinking regarding this problem?

ben_w 6y ago
3mm rather than 3cm, but also note that full CPUs have to run slower than the upper limit of the transistors inside them, because most operations need to go through multiple transistors.
jjoonathan 6y ago
Caches are already closer than 3cm and can take multiple cycles to fetch from. DRAM takes 100s of clock cycles to fetch from! It's bad -- but the badness was already here. Propagation delay problems are real, but for caches IIRC the biggest problems are transmission lines being lossy and having propagation speeds much slower than the speed of light in a vacuum, and for DRAM the biggest problems are waiting for precharge and waiting for the sense amplifiers to stabilize. Waiting for the precision required to read obscenely small capacitors, in other words. If DRAM is 1T1C and SRAM is 6T, I always wondered why we couldn't just have DIMMs of SRAM at 1/3rd the capacity or whatever. Overprovisioning DRAM by that factor is already common, wouldn't eliminating all the downtime be a way to put that slack to work? Like the HDD -> SSD transition? Ah well, I'm sure there's a constraint I'm just not thinking of.
- simcop2387 6y ago
  You'd need a different CPU these days since the memory controller for sram would be a bit different. That said you do see sram in smaller embedded systems because it's also easier to drive and work with signal wise. I bet someone's done it as a research project with larger CPUs but I bet the cost of the SRAM and the cost of a niche cpu design just made it all not viable in the market place.
  - jjoonathan 6y ago
    Right, memory controllers wouldn't be able to fully leverage SRAM DIMMs right out of the gate, but they would be able to partially leverage them right out of the gate and fully leverage them within a JEDEC cycle. It has been multiple JEDEC cycles since over-provisioning became common, so I suspect there must be something else preventing this. SRAM costs way more, but afaik that's an artifact of market size, not fundamental. Hence the 1T1C vs 6T comparison to tease out the fundamental cost difference, which looks to be not worse than 3x-6x more expensive, which would put SRAM DIMMs will within reach. I lean on heinously expensive SRAM in my own embedded designs and would really like to see some market scale drive down those costs!
- lowbloodsugar 6y ago
  I was going to be really disappointed if this page's comments didn't involve the word "capacitor" at some point.
avmich 6y ago
Asynchronous schemes don't need to propagate clock through the whole scheme, so they don't have this limitation.
klyrs 6y ago
One thing to note is that this is a bit-serial adder. If you use this to perform, say, 32-bit arithmetic, then the effective clock rate is about 3GHz. Half that for 64-bit. Compare this to a PCIe4 bus, which is clocked at 16GT/s -- that is, each "lane" runs at 16GHz and is used to transmit data around serially instead of routing more wires around to make a wider bus. That's readily-available (damn the chip shortages) tech, but we can't buy 16GHz general-purpose processors.
- mlyle 6y ago
  It's a bit-serial adder not for any technical reason other than it's a convenient benchmark for characterization of the logic within. You could obviously use the process to make wide adders with faster clock speeds than stacking serial adders in front of each other.
  - klyrs 6y ago
    I'm sorry, but that's not obvious. Given that we've got PCI circuits running at 16GHz, why don't chipmakers give us full-scale processors with those faster clock speeds? Bit-serial adders are extremely simple circuits with a single carry register, which can run at essentially the full speed of the underlying switching devices. Ripple-carry adders have a circuit depth proportional to the number of bits in the adder -- they're only stable when the clock is substantially slower than the switching time (proportional to the circuit depth), because the carry signal needs to propagate through all of the 1-bit adders.
    - mlyle 6y ago
      > I'm sorry, but that's not obvious. Given that we've got PCI circuits running at 16GHz, why don't chipmakers give us full-scale processors with those faster clock speeds? That's not what I said. I'm just saying that it's obvious that if you wanted a fast 64 bit adder on the process, you'd build a carry lookahead adder or other fast adder, not stack a single bit adder 64 times. Saying "YOU NEED TO MULTIPLY PROP TIME BY 64" seems kinda dishonest. I said: > > You could obviously use the process to make wide adders with faster clock speeds than stacking serial adders in front of each other. Do you really think the optimum thing is going to be stacking 64 of these in a row?
api 6y ago
There would definitely be applications for a tiny ultrafast serial CPU with on-board RAM. Not all algorithms are parallelizable. I'm imagining a small in-order 32-bit core with ~256KiB static RAM running at 100ghz. Call it the Serial Killer.
rbanffy 6y ago
I remember research on asynchronous (or clockless) CPUs. Philips had an asynchronous ARM demonstrator. Where did that go?
fctorial 6y ago
Million core processors, with each core in micrometer range, and threads occupying cores permanently. Cores will be assigned to processes like tiktaks (memory). Probably similar to the transition from bytes of ram to kbs of ram. Will be interesting to see how software expands to fill that space. Every program will become a distributed program. Supercomputers of today will be a commodity tomorrow.
universal_sinc 6y ago
Just so everyone is aware of the scales involved in modern circuits, an entire CPU Core like in Snapdragon 865 might only take up an area of ~3mm2, measuring just ~1.75mm across. 3mm gets you across the CPU and back again. We think in nanometers and picoseconds down here. (Not withstanding signals travel much slower than the speed of light in our tiny copper wires, remember t=RC)

ben_w 6y ago

3mm rather than 3cm, but also note that full CPUs have to run slower than the upper limit of the transistors inside them, because most operations need to go through multiple transistors.

jjoonathan 6y ago

Caches are already closer than 3cm and can take multiple cycles to fetch from. DRAM takes 100s of clock cycles to fetch from! It's bad -- but the badness was already here. Propagation delay problems are real, but for caches IIRC the biggest problems are transmission lines being lossy and having propagation speeds much slower than the speed of light in a vacuum, and for DRAM the biggest problems are waiting for precharge and waiting for the sense amplifiers to stabilize. Waiting for the precision required to read obscenely small capacitors, in other words. If DRAM is 1T1C and SRAM is 6T, I always wondered why we couldn't just have DIMMs of SRAM at 1/3rd the capacity or whatever. Overprovisioning DRAM by that factor is already common, wouldn't eliminating all the downtime be a way to put that slack to work? Like the HDD -> SSD transition? Ah well, I'm sure there's a constraint I'm just not thinking of.

simcop2387 6y ago
You'd need a different CPU these days since the memory controller for sram would be a bit different. That said you do see sram in smaller embedded systems because it's also easier to drive and work with signal wise. I bet someone's done it as a research project with larger CPUs but I bet the cost of the SRAM and the cost of a niche cpu design just made it all not viable in the market place.
- jjoonathan 6y ago
  Right, memory controllers wouldn't be able to fully leverage SRAM DIMMs right out of the gate, but they would be able to partially leverage them right out of the gate and fully leverage them within a JEDEC cycle. It has been multiple JEDEC cycles since over-provisioning became common, so I suspect there must be something else preventing this. SRAM costs way more, but afaik that's an artifact of market size, not fundamental. Hence the 1T1C vs 6T comparison to tease out the fundamental cost difference, which looks to be not worse than 3x-6x more expensive, which would put SRAM DIMMs will within reach. I lean on heinously expensive SRAM in my own embedded designs and would really like to see some market scale drive down those costs!
lowbloodsugar 6y ago
I was going to be really disappointed if this page's comments didn't involve the word "capacitor" at some point.

avmich 6y ago

Asynchronous schemes don't need to propagate clock through the whole scheme, so they don't have this limitation.

klyrs 6y ago

One thing to note is that this is a bit-serial adder. If you use this to perform, say, 32-bit arithmetic, then the effective clock rate is about 3GHz. Half that for 64-bit. Compare this to a PCIe4 bus, which is clocked at 16GT/s -- that is, each "lane" runs at 16GHz and is used to transmit data around serially instead of routing more wires around to make a wider bus. That's readily-available (damn the chip shortages) tech, but we can't buy 16GHz general-purpose processors.

mlyle 6y ago
It's a bit-serial adder not for any technical reason other than it's a convenient benchmark for characterization of the logic within. You could obviously use the process to make wide adders with faster clock speeds than stacking serial adders in front of each other.
- klyrs 6y ago
  I'm sorry, but that's not obvious. Given that we've got PCI circuits running at 16GHz, why don't chipmakers give us full-scale processors with those faster clock speeds? Bit-serial adders are extremely simple circuits with a single carry register, which can run at essentially the full speed of the underlying switching devices. Ripple-carry adders have a circuit depth proportional to the number of bits in the adder -- they're only stable when the clock is substantially slower than the switching time (proportional to the circuit depth), because the carry signal needs to propagate through all of the 1-bit adders.
  - mlyle 6y ago
    > I'm sorry, but that's not obvious. Given that we've got PCI circuits running at 16GHz, why don't chipmakers give us full-scale processors with those faster clock speeds? That's not what I said. I'm just saying that it's obvious that if you wanted a fast 64 bit adder on the process, you'd build a carry lookahead adder or other fast adder, not stack a single bit adder 64 times. Saying "YOU NEED TO MULTIPLY PROP TIME BY 64" seems kinda dishonest. I said: > > You could obviously use the process to make wide adders with faster clock speeds than stacking serial adders in front of each other. Do you really think the optimum thing is going to be stacking 64 of these in a row?

api 6y ago

There would definitely be applications for a tiny ultrafast serial CPU with on-board RAM. Not all algorithms are parallelizable. I'm imagining a small in-order 32-bit core with ~256KiB static RAM running at 100ghz. Call it the Serial Killer.

rbanffy 6y ago

I remember research on asynchronous (or clockless) CPUs. Philips had an asynchronous ARM demonstrator. Where did that go?

fctorial 6y ago

Million core processors, with each core in micrometer range, and threads occupying cores permanently. Cores will be assigned to processes like tiktaks (memory). Probably similar to the transition from bytes of ram to kbs of ram. Will be interesting to see how software expands to fill that space. Every program will become a distributed program. Supercomputers of today will be a commodity tomorrow.

universal_sinc 6y ago

Just so everyone is aware of the scales involved in modern circuits, an entire CPU Core like in Snapdragon 865 might only take up an area of ~3mm2, measuring just ~1.75mm across. 3mm gets you across the CPU and back again. We think in nanometers and picoseconds down here. (Not withstanding signals travel much slower than the speed of light in our tiny copper wires, remember t=RC)