Hacker News Reader

Comment by smallnamespace | Hacker News Reader

That's completely false. The speed of light today already constrains processor design (and by extension, on-CPU caches):

http://arstechnica.com/science/2014/08/are-processors-pushin...

"Even if signals in the chip were moving at the speed of light, a chip running above 5GHz wouldn't be able to transmit information from one side of the chip to the other". Note that a light-nanosecond is about a foot, so I'm assuming this is talking about the propagation delay of electrons in silicon that need to go through gates, which I'm sure is much slower than light in a vacuum.

To put this another way, you can view the scaling law as a hard upper bound on the speed of access to data; engineers can only approach that bound from below as technology improves.

But given a certain level of technology, it's easier to make a faster L1 cache than an L2 cache, and that will hold even as we approach theoretical limits.

View on HN

A bit of a nit: We're not worried about the propagation of electrons over distance as much as we're worried about the propagation of the electric field. Electrons move too slow, the electric field moves much faster.

https://en.wikipedia.org/wiki/Velocity_factor

> which I'm sure is much slower than light in a vacuum.

Speed of signal in copper is about ⅔c, I suspect silicon will be in a similar ballbark – and the metal layers linking the silicon layers are made of copper anyway. So it's about 8"/ns… and the (three dimensional, 10+ layer) signal routes are anything but a straight line.

And the signals all need to get there at the same time

And that's such a hard problem that you don't even have to go down to CPU scale for it to matter.

If you look at mainboards (or some smaller PCBs), the connecting lanes between e.g. RAM and CPU closer to the centre are often zigzagged, to match the lengths – and delays – of the necessarily longer outer lanes. The speed of light is actually really damn slow.

> The speed of light is actually really damn slow.

I don't think one really appreciates that until they found out that after X hours of place&route they missed timing by some fraction of a nanosecond

> you don't even have to go down to CPU scale for it to matter.

It's say it's the opposite, really. The longer the wires, the more effort it takes to synchronize their delays within a certain number of picoseconds.

Well, not entirely. For data signals in general you just need all the lines to resolve to the desired value before the clock. You do need to be very careful about the clock, though.

Well yeah, I figured that that's implied, the only times that really matter are the rising and falling edges of the clock.

DDR4-SDRAM achieves speeds in excess of 1.2 GHz over distances of 4" or more. That doesn't leave too much wiggle room.

Surprisingly, the behavior at that speeds is fairly well known. I don't even think you need to move from FR4 to a more controlled material (e.g.generally in mmWave, Isola FR408, along with sometimes Rogers stuff, IME, is what is used). Allegro PCB SI(Signal Integrity) even models high speed timing fairly well at the design stage.

You've got plenty of stuff at the test stage too. E.g., the gear on high-end Lecroy's metrology test gear is at 100ghz. Agilent (Keysight, whatever, it's still HP to me) has a full test rig for USB3.1[0] at 10gbps for their consumer level gear (again, fairly slow). Step it up to FPGA speeds and here's[1] an app-note by Altera with way higher speeds.

Here's a really brief overview of 'rules of thumb' that work up to PCI-e[2] by TI. 50 minutes and worth a watch. Clean power that won't couple in, matching lines lengths on diff pairs, proper isolated ground planes (give AGND and DGND their own layers) and proper termination will easily get you 95% of the way there.

(Shameless promotion-- available for high-speed design, pre-EMC compliance testing, fault diagnostics, etc).

[0] http://www.keysight.com/en/pd-2472798-pn-U7243B/usb-31-compl... [1] https://www.altera.com/en_US/pdfs/literature/an/an528.pdf [2] https://www.youtube.com/watch?v=A3qw_Ecx9Co

Note that GDDR5 abandoned length matching, and just measures the latencies of each wire to calibrate itself.

The speed of the signal depends on the properties of the surrounding medium though, right? You get one speed through copper in air but another speed entirely for copper in silicon.

And another for pure silicon, and others for the various doped silicons, …

I don't even know what the actual materials are with current technologies, but whatever it is, the speed will be much lower than the vacuum speed of light.

Well, that depends on the context. You're totally right in general, but for the purpose of order-of-magnitudes of maximal clock rates, the speed of light hardly varies. I can't find any normal, plausible processor material with a refractive index of 4, let alone 10. So while light in silicon may well travel [almost 3.5 times](http://refractiveindex.info/?shelf=main&book=Si&page=Chandle...) more slowly than in a vacuum - which is hardly nothing, at the granularity we're talking about I think it's not a huge issue. But that's just perspective - clearly the materials matter and will affect signal transmission speeds, and probably even today impose significant (if indirect) limitations.

It's possible weird dopings or quantum effect change this dramatically, I suppose. But if I had to guess, they don't.

>"Even if signals in the chip were moving at the speed of light, a chip running above 5GHz wouldn't be able to transmit information from one side of the chip to the other".

That's almost completely misleading. Except for the clock itself, nothing that happens inside a processor takes a single clock cycle. And clock distribution delays need compensation anyway.

That's also true of memory. No one has ever seen 1-0-0-0 CAS RAM. (And no one ever will.)

It's true that pushing up against distribution times makes topology more complicated and lowers the maximum possible speed.

But that's actually the difference between electronics and photonics, which promise to run many orders of magnitude faster than EM-based silicon design. (I've seen "millions" quoted, but that may turn out to be hyperbole. Even so - optical fibre can run at tens of Tbps.)

Of course there's a difference between transmission speed, which is a function of the speed of light, and maximum data rate, which is a function of bandwidth.

But unlike electrons-in-silicon connections, photonics may not need to be 100% serial. It's entirely possible to get multiple data channels down a single line with frequency multiplexing, and perhaps also by phase rotation.

That has huge potential to change the packing density and the speed of processor designs; potentially you could have processor elements that were massively parallel but connected with single lines.

There's also some hope that because power dissipation shouldn't be such a problem, it will be easier to make 3D designs - although that's probably more speculative.

Bottom line is silicon is nearly done, but photonics is just getting started. Like fusion power it's probably a couple of decades away, but when it arrives it will be huge.

So, what you're really saying is that it's quite accurate, there are just details and more details but in the end - as long as we use a single clock - signals need to be able to travel from one end to the other in a single clock cycle.

Now, if we had (partially) clockless processors...

Also, your details are a lot more misleading than those in the article. lots of things in a modern processor take 1 clock cycle. Agner has lovely tables:www.agner.org/optimize/ and note that most basic integer and floating point operations on a skylake processor take 1 cycle - things like bit shuffling, moving, adding (not floats), and quite a few incidental other operations. Now, I'm sure you can quibble that a latency of 1 cycle in that table isn't really 1 cycle under some unusual interpretation of what's going on, but at that point you're quibbling about what "doing something" means, which isn't helpful. What programmers/compiler writers call 1 clock cycle can execute what most people call 1 instruction for many common instructions, even today.

On the massively-parallel-connected-with-single-lines theme, there's been some interesting work done with on-chip RF, which does essentially the same thing with conventional silicon.

Most stuff that happens inside processors takes a single cycle, and we used to have single-cycle RAM until the CPUs ran away with increasing speed.

Photonics has a serious density problem: visible light is too large in terms of wavelength. This is already an issue with etching silicon. It's also at best at the 1950s stage where people have developed single photonic transistors in the lab but not yet photonic VLSI.

Anyway, the main factor of delay in chips is capacitance, both between wires and on the gates of FETs. This must be charged through the on resistance of the driving FET and all the intermediate wiring.

All cache (and in fact, memory as well) used to be single-cycle.

Why aren't they any more? Because the speed of light doesn't allow it.

Multi-cycle cache/memory latency and the cache hierarchy it implies is a result of being bound by the speed of light.

If anyone talks about signals crossing the chip in a single cycle, they're barking up the wrong tree. It's absolutely unnecessary. It would not take a tremendous engineering work to make a CPU where signals go no more than 3mm or even 1mm in a cycle. (At 5GHz you have a distance budget of over 40mm.) The most important constraint for single-threaded operation is transistor switching time. It's likely the most important constraint will always be transistor switching time.

Transistor switching time is limited mostly by electrical capacity which is determined by the permittivity of the material the transistor is made from. And permittivity and permeablity are the only things determining the speed of light in a material. So saying that speed of light is the limiting factor of transistor switching time is valid.

Reply on news.ycombinator.com