Sun Unveils Direct chip-to-chip Interconnect

mfago writes "On Tuesday September 23, Sun researchers R. Drost, R. Hopkins and I. Sutherland will present the paper "Proximity Communication" at the CICC conference in San Jose. According to an article published in the NYTimes, this breakthrough may eventually allow chips arranged in a checkerboard pattern to communicate directly with each other at over a Terabit per second using arrays of capacitively coupled transmitters and recievers located on the chip edges. Perhaps the beginning of a solution to the lag between memory and interconnect speed versus cpu frequency?"

Comments

No registration

[Anonymous Coward]

Via Google

Re:IANAEE (I am not an electrical engineer)

[Anonymous Coward]

You can't simply just remove the circuit board to achieve better speeds, you need to eliminate the need for the pad that converts internal logic to what we currently use externally. That is what Sun is claiming they have done.

Sun's technology is not simply soldering to pins directly together (as you suggest), which is effectively the same thing as wiring through a circuit board. The high speed, low drive strength, low-voltage drivers have to go through pads that convert the internal signal to a slower, high drive strength, high voltage driver, that will yield a reliable connection to the next chip. I'm not an expert in this area, but Physics just gets in the way. There are capacitive issues, and interconnect delay issues.

Sun is claiming to use capacitive coupling (put the pins really close together, but don't physically connect them.) This way they don't have to drive the external load of the pin/board connection, and are claiming they will be able to scale this down to a pad that will be able to switch faster than existing physical wire connected pins. Which means they believe they can make this technology work with lower drive stengths.

They still have a ways to go. Notice that the P4 has faster connections using existing techology. Sun did a proof of concept, and claim they can speed it up 100x. So they haven't _proved_ that this will operate faster yet. They still have many things to overcome to make this viable, including how to make a mass production/assembly process. It's going to be a few years. At least.

Re:IANAEE (I am not an electrical engineer)

[eXtro]

There are two seperate metrics that define the speed of memory. Latency, which is what your 40 ns refers to, and bandwidth. Large caches address the latency problem as you stated. If you want to transfer more bits per cycle you're restricted due to signal integrity issues related to the bus, so the parent post is also correct. You can increase the width of the bus, up to a point, and get a small scalar increase in bandwidth. To go beyond this you need to address signal integrity problems.

Sending fast edges over a bus is difficult because the signal degrades:

• inter-signal interference: Each parsel of information spreads due to the RC nature of the bus so that it takes up more than a period, thus interfering with the next packet.
  
• cross-talk: Each wire on the bus is fairly tightly coupled with it's neighbours, so switching activity on one wire affects it's neighbours.
  
• transmission line effects: Package connectors, bends in circuit traces etc all create impedance mismatches. This causes reflections which degrade the signal.
  

If your dataset fits into the cache well, which is often the case for PCs, then a cache can fix most of your problems. If you're dealing with datasets that span gigabytes or terabytes and your application can't be subdivided such that processing and memory can be constrained per cpu then your cache doesn't assist you very much.