Slashdot Mirror
A Look at Photonic Clocking
zymano writes "In an article on the Electronic Engineering Times site James Siepmann shares a few thoughts about Photonic Clocking. Siepmann states: 'Copper interconnects are reaching their limit as data-transmission bandwidth and processor speed continue to rise. [..] Photonic clocking not only solves the limitations of electronic clocking, but also reduces jitter, skew, delay, crosstalk and power consumption while maintaining clock signal integrity for longer distances.'" Are Photonic Processors the next logical step, or will the almighty buck shuffle them aside because of cost?
The article didn't say a whole lot, did it? It just said, "Gee, wouldn't photonic clocking be nice". It didn't say a whole lot about how, and whether it's feasible.
So, I'll quickly fill in what I know. To do clock distribution you need two types of components: waveguides and detectors. Let's assume you are going to work in silicon...
Waveguides function as the optical wiring, and includes things like bends and splitters. Although perhaps not trivial, it is relative straight-forward to make waveguides in or on silicon. Detectors, on the other hand, are not so easy, at least at the wavelength most people are interested in, 1550 nm. There's a number of people researching Ge growth for detectors on Si, and this does have promise, but it's not ready yet. Another option would be bonding InGaAs, but that might always be too expensive.
Now, if you want to do full up optical communication, on chip, you'll want modulators, too. These have been demonstrated by Intel and Cornell in silicon, but only at speeds around 1 Ghz. Optical amplifiers would be nice, too, and this has been demonstrated (using Raman amplification) by Intel and UCLA. (I'm not sure Raman amplification can give you the sorts of amplification and efficiency you really need, though).
(Sorry, I won't be able to respond to any replies; at least not until Monday. I'm off to bed and I'm not planning to be near a computer tomorrow).
Distributing your clock with photons imples you have a photon wave guide. If you are going to build a photon wave guide then why not build an electrical wave guide. Electrical wave guides, like for example coax cable, have wave velocities that are faster than light in glass, so they would logically be even better. And you dont' need any special materials like you would for optical wave guides.
The problem might be that usually wave guides have to be the size of the wavelength to work right. ghz wavelength are larger than the chip. Thus you get forced towards the optical region by this considerarion.
But you can beat this two ways.
1) use negative index of refraction materials. Then the waveguide can be smaller than the wave length
2) use near field waveguides with amplification. When the wavelength is a lot larger than the waveguide then the wave becomes evanscent (decaying). So it can't propagate very far. But hey, that's okay because the chip is not very wide either, so we can tolerate some loss of signal. And we could toss in some amplification to offset it.
Some drink at the fountain of knowledge. Others just gargle.
Transistors don't need clocks, logic gates don't need clocks, but flip-flops do. The reason you need a clock is because the outputs of a bit of logic will be 'unstable' for a while the result is computed. The clock tells the next piece of the system when to read. In place of that, you'd need a 'done' signal, which would rase transistor counts quite a bit. Not to mention it would be very hard to find people who would know how to design these things. I think the future of the CPU involves different parts of the system operating on separate clocks, transferring data via a 'networking' type system. Computers connected via Ethernet don't need to have their clocks synched in order to work. Think of a simple instruction decoder. The decoder reads the instructions, and opens the right 'gates' in the CPU so that there is an electrical connection between the two registers and the ALU, and inside the ALU to the adder or subtractor, or whatever depending on what instruction you're trying to run. Then, the clock signals and tells the ALU that the registers are ready. Without the clock, the ALU might try to add the wrong things. (the ALU doesn't need a clock to work) In the future you could have some sort of system where the decoder just sends a message to the ALU telling it to setup the adder, and to the registry file to access these two registers. Then the register file will send the data to the ALU whenever it's ready.
autopr0n is like, down and stuff.
Not a credible player.
Back in the day, "real" computer manufacturers scoffed at Intel. IBM would only let them produce the chips for the PC after Intel found another manufacturer willing to produce the part in case Intel tanked. The PC was nothing to boast about compared to the mainframes of the day.
Slowly but surely, Intel grew to become the monster they are today. The turning point was somewhere near the Pentium II, when Intel machines were beginning to be used as engineering workstations. Profits truly are the source of competition and progress. Back then, the PC market was small, and improvements came quickly only because things were relatively simple. Now, everyone wants a piece of a growing pie, and companies are innovating as fast as possible.
Ethernet does rely on synchronised clocks. You might be misstating that Ethernet doesn't have a clock line, meaning there is no dedicated wire with a clock signal on it.
There is a high-precision clock on every Ethernet card. An Ethernet frame has a 64-bit preamble with Manchester encoding. That preamble adjusts the skew of the receiver clock so that it's synchronised with the transmitter clock. If the synchronisation didn't occur, you wouldn't know when to latch the data on the line and you couldn't receive a frame. The synchronisation occurs on every Ethernet frame and the precision of the clock must be high enough that the synchronisation lasts for the length of a frame.
Async architectures will likely use a similar technique. The subsystems won't be driven by a system-wide clock line, as in the existing synchronous architectures, but the various clocks in subsystems will certainly be synchronised.
erm ... a waveguide is a waveguide, no matter what kind of terminators you use. The pertinent condition is to support propagation modes.