Good luck
Good luck
Posted Feb 27, 2025 11:12 UTC (Thu) by Wol (subscriber, #4433)In reply to: Good luck by PeeWee
Parent article: Building an open-source battery
That's the point. That is the time required for a signal to travel from one side of a mobo to another. So in order for a component to receive a response - ANY response - from a component on the other side of the mobo - it's impossible for the mobo to run faster than 500MHz. A chip is an order of magnitude smaller, so it can run an order of magnitude faster.
Getting round the speed of light is what I meant by "cheating". You mention making sure the clock signal arrives everywhere at the same time. CPUs have pipelines. Etc etc. But at the end of the day, if you want two components to talk to each other, you have to assume that that communication cannot happen faster than 500MHz without "cheating". Be it squeezing components as tightly together as possible, predictive pipelines, all sorts of fancy tricks to give the illusion of faster than light.
Cheers,
Wol
Posted Feb 27, 2025 11:28 UTC (Thu)
by PeeWee (guest, #175777)
[Link] (5 responses)
Posted Feb 27, 2025 14:51 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (4 responses)
The external clock frequency supplied to a CPU is much less than the internal CPU clock frequency; I think it's this external clock Wol was referring to. The internal clock is generated via a clock multiplication circuit and a PLL.
Posted Feb 27, 2025 15:07 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
But if you don't want to stall the bejeezus out of your chip, you can't go any faster than that ... (without pipeline/magic "cheating" etc etc.)
Cheers,
Posted Feb 27, 2025 16:56 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (1 responses)
10Gb/s ethernet over copper has multiple bits "in-flight" on the cable if it's more than a few metres long.
A technical challenge sure, but not impossible.
Posted Feb 28, 2025 9:22 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
Posted Feb 27, 2025 16:10 UTC (Thu)
by atnot (subscriber, #124910)
[Link]
Posted Feb 27, 2025 13:52 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (4 responses)
Where size becomes an issue is where latencies are critical - if a device is small, everything can be assumed to happen in a single clock cycle, but as the scale increases, the minimum latency also increases. You thus have an extra layer of complexity when clocks increase, because you can no longer place devices freely; you have to allow for latency issues.
But all this actually means is that various simplifying assumptions that hold at 20 MHz stop holding at 200 MHz, and simplifying assumptions that hold at 200 MHz don't hold at 200 GHz. Instead, as the frequency increases, the amount of real-world physics you have to take into account also increases.
Posted Feb 28, 2025 9:26 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (3 responses)
Posted Feb 28, 2025 10:19 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
As frequency increases, you quantise the possible latencies of an operation into more buckets; a signal travelling 2 cm in a typical chip takes about 0.1 nanoseconds to do that (speed of light in a silicon chip is about 2/3rds of that in a vacuum). If your clock cycle time is 1,000 nanoseconds, then it's easy to ensure that everything in your chip is at most half a cycle time away from everything else.
But if your clock cycle time is now 0.2 nanoseconds (5 GHz), you have to place the latency sensitive parts with care; you need the things that cannot wait more than 1 clock cycle to be safely under 4 cm apart at their furthest extents, because even 4cm is too far to be reliable (since logic has its own delays and required timings to meet when the signal enters and exits part of the chip). You can put things that can tolerate a 10,000 cycle delay at 5 GHz on different chips on a motherboard, since your 10,000 cycle delay is 2 microseconds, giving you about 300 meters, even as you put things that cannot tolerate more than 1 cycle latency 2 cm apart.
Note though, that this doesn't make 5 GHz impossible on a chip that's 80mm by 80mm; it just means that you have to work a lot harder on chip layout for a 5 GHz chip than you do for a 2 GHz chip of the same size.
Posted Feb 28, 2025 11:50 UTC (Fri)
by malmedal (subscriber, #56172)
[Link] (1 responses)
The speed you can signal on is governed by the telegraphers equations.
The answer is complicated and depends on the process technology. In 28nm I believe the typical speed of signal propagation is around 20% of light-speed, there are things you can do on the chip to make it faster, at the cost of space and power.
Posted Feb 28, 2025 16:26 UTC (Fri)
by malmedal (subscriber, #56172)
[Link]
This article gives a speed of 1200 ps/mm for a 5nm node:
https://semiengineering.com/slower-metal-bogs-down-soc-pe...
speed of light is 3.3ps/mm...
Good luck
Good luck
Good luck
Wol
Good luck
Good luck
Good luck
You're looking at the single-cycle latency limit, and asserting that it's impossible for the motherboard to cope with multi-cycle latencies. In practice, we can happily use gigahertz signals over kilometers of distance (such as in mobile phone networks) by "pipelining"; you send a request signal, knowing that the response to the signal you've just sent will be multiple clock cycles later. Even better, as long as you allow for propagation delays, you can send a sequence of signals (timed by the clock), to be handled by the remote end as they arrive, in a "pipelined" fashion.
That ignores pipelining
That ignores pipelining
That's what I was getting at when I wrote:
That ignores pipelining
Where size becomes an issue is where latencies are critical - if a device is small, everything can be assumed to happen in a single clock cycle, but as the scale increases, the minimum latency also increases. You thus have an extra layer of complexity when clocks increase, because you can no longer place devices freely; you have to allow for latency issues.
That ignores pipelining
That ignores pipelining