4 ms·

Power, heat and the speed of electrical signal. Power use increases quadratically with voltage. You want small transistors to keep the voltage and power use

Power, heat and the speed of electrical signal. Power use increases quadratically with voltage. You want small transistors to keep the voltage and power use from getting out of hand. You also need to increase voltage if you want to increase clock speed. Electric signal travels in a conductor roughly 15 cm/nsec. With 3 GHz clock speed the electric signal travels travels roughly 50 mm in one clock cycle. Largest microchips are 30 mm across. You can't double the dimensions without dealing with the signal lag. Delivering the clock signal to every part of the chip in sync is already a problem. Modern microchips use lots of extra circuitry just to deliver the clock signal properly.

codemusings 9y ago
Thank you for your answer. Very interesting. I was vaguely aware of how clock cycles work but the signal lag problem didn't even occur to me.
- veritas3241 9y ago
  I highly recommend Code by Charles Petzold. Personally, it helped me to have a more intuitive understanding of clock cycles and the underlying architecture of computers. https://www.goodreads.com/book/show/44882.Code https://www.goodreads.com/book/show/44882.Code
vinn124 9y ago
the quality and preciseness of this answer is why i read hn every day.
slivym 9y ago
Whilst it's true that modern chips have problems with routing clocks, that's not really a limiting factor in chip size. You split the design into clock regions and have clock crossing logic. There's obvious ways this happens - multi-core designs have different clocks for different cores for example. That's not really the limiting factor for chip size.
- Nokinside 9y ago
  The cost of clock regions is slower speeds between tiles and more transistors and power wasted in clock management. In the end you need need buffers and cache for cache for cache to maintain speed and locality. All this wastes transistors.
kingosticks 9y ago
> You also need to increase voltage if you want to increase clock speed. Or use lower VT cells (they turn "on" quicker), at the expense of increased leakage power. But at these geometries, faster clock speeds is getting less feasible and you need to find increased performance in other ways. No logic signal needs to cross the entire die in one clock cycle, there is always an alternate design. For that reason, only registers 'talking' to each other need to see a clock at the same time, and even then there is a window. Clock routing is a consideration that takes resources but it's not a problem. Realistically, a logical signal won't be going anywhere remotely near 50mm at 3GHz in 10nm, so the clock doesn't need to either. Max die size is also limited by the vendor's tooling i.e. what their machines can literally handle. And also physical issues such as warpage. If you make a massive die and it heats up in a non-uniform manner (different bits of it get hot at different times), it expands in a non-uniform manner. This can lead to all kinds of problems. Chips stuffed full of memory will yield better than a logic-heavy chip since large SRAMs always now include redundancy. So this too has an impact on how big you can go for a given cost. You can however get registers that are built of multiple storage elements, the output value of which is the consensus. Don't know how much these get used.
- Nokinside 9y ago
  Numbers I mentioned are just physical maxims. In reality its the signal speed relative to jitter, time interval errors and data setup times that complicate the design and signal integrity. If the clock is 3GHz, the margin of error is the fraction of the time of the clock rate. You need to divide the chip into clock regions and add local cache for each core because fetching data far away is too slow.
  - kingosticks 9y ago
    Sure, but that's all independent of the size of the chip.
fyi1183 9y ago
Do you have a good source on how clocks work in modern designs? From the high level down to the actual circuits? I've always wondered why you can't generate clocks locally, but in a synchronized way. So basically like clock regions, but without having to add extra logic for data that goes between regions.
- dragontamer 9y ago
  You can do this. Its called a "bus". CPUs communicate over a bus (ex: AMD's SerDes, which creates the Infinity Fabric. Or Intel's "Mesh Network") with each other on the die itself. CPU Cores use a singular clock. But when cores communicate or the L3 cache communicates (cache coherency is needed if you want that mutex / spinlock to actually work), then you need some kind of communication mechanism between the CPU Cores. Those clocks are likely "locally generated", but there needs to be a translation mechanism between Bus -> Core.
  - fyi1183 9y ago
    It's possible I misunderstand you, but I don't think we're talking about the same thing. With buses, you have different clocks and data moves between them. Like you said: CPU core 1 has its own clock, the bus between them has its own and different clock, and then CPU core 2 has its own clock which is yet again different. And in those cases you actually want different clocks, because you want to be able to boost CPUs independently from each other. What I meant goes in another direction: instead of having a single powerful clock source for e.g. a CPU core, you have multiple smaller clock sources distributed throughout the core, but synchronized to each other so they run at the same frequency and phase. So data can move freely like it does today, but clock signals don't have to be distributed as far, which would hopefully make clock distribution easier and less power hungry. It seems like such a thing should be possible, but perhaps there are good reasons why it isn't done?
    - dragontamer 9y ago
      Two things: 1. Clocks don't use a lot of power. Think of a pendulum: there's a lot of movement but the energy constantly swings between gravitational potential energy and kinetic energy. Although there's lots of movement, the device uses very little energy. Similarly, a clock circuit (called an oscillator) barely uses any electricity: it mostly "Swings" energy back and forth between an inverter and a capacitor. 2. Distributing a clock over a long distance similarly uses very little power (!!) due to transmission line theory. You can effectively use the parasitic capacitance in wires themselves to effectively do this pendulum effect for efficient long-distance transmission of clocks. See: https://en.wikipedia.org/wiki/Transmission_line https://en.wikipedia.org/wiki/Transmission_line This gif shows an animation of the pendulum effect in a longer-transmission line: https://upload.wikimedia.org/wikipedia/commons/8/89/Transmission_line_animation_open_short2.gif https://upload.wikimedia.org/wikipedia/commons/8/89/Transmis... ---------------- I guess things could be de-sync'd for more efficiency. But your question is kind of like "Well, can't we get rid of V-Tables in C++ to make branch-prediction more efficient??" I mean, we can. But V-Tables / Polymorphism really doesn't take a lot of time. We only do that if the performance gain really matters.

codemusings 9y ago

Thank you for your answer. Very interesting. I was vaguely aware of how clock cycles work but the signal lag problem didn't even occur to me.

veritas3241 9y ago
I highly recommend Code by Charles Petzold. Personally, it helped me to have a more intuitive understanding of clock cycles and the underlying architecture of computers. https://www.goodreads.com/book/show/44882.Code https://www.goodreads.com/book/show/44882.Code

vinn124 9y ago

the quality and preciseness of this answer is why i read hn every day.

slivym 9y ago

Whilst it's true that modern chips have problems with routing clocks, that's not really a limiting factor in chip size. You split the design into clock regions and have clock crossing logic. There's obvious ways this happens - multi-core designs have different clocks for different cores for example. That's not really the limiting factor for chip size.

Nokinside 9y ago
The cost of clock regions is slower speeds between tiles and more transistors and power wasted in clock management. In the end you need need buffers and cache for cache for cache to maintain speed and locality. All this wastes transistors.

kingosticks 9y ago

> You also need to increase voltage if you want to increase clock speed. Or use lower VT cells (they turn "on" quicker), at the expense of increased leakage power. But at these geometries, faster clock speeds is getting less feasible and you need to find increased performance in other ways. No logic signal needs to cross the entire die in one clock cycle, there is always an alternate design. For that reason, only registers 'talking' to each other need to see a clock at the same time, and even then there is a window. Clock routing is a consideration that takes resources but it's not a problem. Realistically, a logical signal won't be going anywhere remotely near 50mm at 3GHz in 10nm, so the clock doesn't need to either. Max die size is also limited by the vendor's tooling i.e. what their machines can literally handle. And also physical issues such as warpage. If you make a massive die and it heats up in a non-uniform manner (different bits of it get hot at different times), it expands in a non-uniform manner. This can lead to all kinds of problems. Chips stuffed full of memory will yield better than a logic-heavy chip since large SRAMs always now include redundancy. So this too has an impact on how big you can go for a given cost. You can however get registers that are built of multiple storage elements, the output value of which is the consensus. Don't know how much these get used.

Nokinside 9y ago
Numbers I mentioned are just physical maxims. In reality its the signal speed relative to jitter, time interval errors and data setup times that complicate the design and signal integrity. If the clock is 3GHz, the margin of error is the fraction of the time of the clock rate. You need to divide the chip into clock regions and add local cache for each core because fetching data far away is too slow.
- kingosticks 9y ago
  Sure, but that's all independent of the size of the chip.

fyi1183 9y ago

Do you have a good source on how clocks work in modern designs? From the high level down to the actual circuits? I've always wondered why you can't generate clocks locally, but in a synchronized way. So basically like clock regions, but without having to add extra logic for data that goes between regions.

dragontamer 9y ago
You can do this. Its called a "bus". CPUs communicate over a bus (ex: AMD's SerDes, which creates the Infinity Fabric. Or Intel's "Mesh Network") with each other on the die itself. CPU Cores use a singular clock. But when cores communicate or the L3 cache communicates (cache coherency is needed if you want that mutex / spinlock to actually work), then you need some kind of communication mechanism between the CPU Cores. Those clocks are likely "locally generated", but there needs to be a translation mechanism between Bus -> Core.
- fyi1183 9y ago
  It's possible I misunderstand you, but I don't think we're talking about the same thing. With buses, you have different clocks and data moves between them. Like you said: CPU core 1 has its own clock, the bus between them has its own and different clock, and then CPU core 2 has its own clock which is yet again different. And in those cases you actually want different clocks, because you want to be able to boost CPUs independently from each other. What I meant goes in another direction: instead of having a single powerful clock source for e.g. a CPU core, you have multiple smaller clock sources distributed throughout the core, but synchronized to each other so they run at the same frequency and phase. So data can move freely like it does today, but clock signals don't have to be distributed as far, which would hopefully make clock distribution easier and less power hungry. It seems like such a thing should be possible, but perhaps there are good reasons why it isn't done?
  - dragontamer 9y ago
    Two things: 1. Clocks don't use a lot of power. Think of a pendulum: there's a lot of movement but the energy constantly swings between gravitational potential energy and kinetic energy. Although there's lots of movement, the device uses very little energy. Similarly, a clock circuit (called an oscillator) barely uses any electricity: it mostly "Swings" energy back and forth between an inverter and a capacitor. 2. Distributing a clock over a long distance similarly uses very little power (!!) due to transmission line theory. You can effectively use the parasitic capacitance in wires themselves to effectively do this pendulum effect for efficient long-distance transmission of clocks. See: https://en.wikipedia.org/wiki/Transmission_line https://en.wikipedia.org/wiki/Transmission_line This gif shows an animation of the pendulum effect in a longer-transmission line: https://upload.wikimedia.org/wikipedia/commons/8/89/Transmission_line_animation_open_short2.gif https://upload.wikimedia.org/wikipedia/commons/8/89/Transmis... ---------------- I guess things could be de-sync'd for more efficiency. But your question is kind of like "Well, can't we get rid of V-Tables in C++ to make branch-prediction more efficient??" I mean, we can. But V-Tables / Polymorphism really doesn't take a lot of time. We only do that if the performance gain really matters.