Reenigne blog

I recently built myself a new computer using an Intel Core i7 920 CPU. This CPU has more pins (well, “lands” actually, since they are just flat conducting areas that touch pins in the socket) than any other yet produced, 1366 of them to be precise. I was wondering why so many were needed, so I grabbed the datasheet and made a map:

Power:
     V_SS
     V_CC
     V_CCPLL
     V_TTA
     V_TTD
     V_DDQ

Memory:
     DDR0 data      other
     DDR1 data      other
     DDR2 data      other

Other:
     QPI data      other
     Other
     reserved

Idle speculation follows (I don’t have any background in CPU or motherboard design):

The pins roughly divide into six sections: two for memory data, one for other memory-related signals, one for power, one for the QPI bus and one that is mostly reserved.

That there are a lot of power pins is not surprising – this CPU can use as much as 145A of current, which is enough to vaporize any one of those tiny connections, so it has to be spread out amongst ~300 of them for each of power and ground. Having two very big pins for power would probably make the mechanical engineering of the CPU much more difficult and would push the responsibility for branching out that power onto the CPU, whereas it is better done by the motherboard.

It’s interesting that the ground lands are mostly spread out but the power lands are mostly together. I’m not sure why that should be – I would expect them both to be spread out. Perhaps the 8 or 9 big groups of V_CC on the north edge each correspond to a single “power line” on the motherboard (and hence are grouped together) while the distributed ground lands are needed to supply electrons for the signal lands.

Three DDR3 channels also use a lot of lands – 192 for data alone and almost as many again for addresses, strobes and clocks.

Another thing that surprised me is that there are so many reserved lands (~250 of them). Initially I thought that this was because the socket was designed before the designers knew how many pins they would actually need, so they made sure to design for the absolute maximum. However, a good chunk of the reserved lands are used by the Xeon 5500 CPUs, which use the same socket – in particular for memory error detection/correction and the second QPI bus (which is presumably in the northwest corner).

Before I started working at Microsoft, I used to always reply to emails by quoting them, breaking up the quoted text into pieces and then replying to each of the pieces directly below, for example:

From: andrew@reenigne.org
To: xyz@example.com
Subject: Re: Hello

Xyz <xyz@example.com> wrote:
> Hello,

Hello!

> how are you today

I'm fine, thank you.

This style is called inline replying with trimming. This is a fine system because the person I’m replying to gets reminded of what they wrote, and I don’t have to write things like “In regards to the part of your email where you asked me how I was today,”.

The most common other system is top posting, which looks like this:

From: andrew@reenigne.org
To: xyz@example.com
Subject: Re: Hello

Hello! I'm fine, thank you.

Xyz <xyz@example.com> wrote:
> Hello, how are you today

This is the natural default with Microsoft Outlook. In the geek circles I had moved in before working at Microsoft, this style was greatly frowned upon. However, it is ubiquitous at Microsoft. I’m not sure whether this is because it’s the default style in Outlook or whether it’s the default style in Outlook because it is ubiquitous at Microsoft. However, once I had forced myself to “do as the Romans do” and top post, I found that it does actually make more sense in that environment. This is for two reasons:

1. When the conversation falters due to lack of knowledge about something, it’s very common to “loop in” an expert to give their two cents by adding them to the CC line. In order for the expert to have some context, it’s useful to have the previous history of the conversation right there in the email, so he or she can read it (bottom to top).
2. With each email carrying the entire thread, emails can get pretty long. It’s inconvenient to have to scroll all the way to the bottom of each email to see the latest reply (especially if you’re just a spectator rather than a contributor to a busy thread) so it’s better for the replies to be at the top than at the bottom.

It’s still useful to reply inline as well sometimes – at Microsoft this is done by quoting the email you’re replying two twice – once, in its entirety, at the bottom and once (suitably chopped and trimmed) inline. I used to do this quite frequently as it’s the best way I’ve found (pre-Argulator) of addressing each point individually. However, one of my managers once told me that if the conversation got sufficiently complex that I felt it was best to do that, I should instead “take it offline” and schedule a face-to-face meeting instead to hash out these issues. However, I felt (and still feel) that inline email replies are better than face-to-face meetings for such complicated issues – in face to face meetings there’s less time to think about your answer, and points can get lost – as the conversation progresses it can only follow one “branch” of the argument tree, and without explicitly maintaining a stack it’s very easy for branches to get forgotten about.

In the not-too-distant future, we’ll hit a limit on how small we can make transistors. The logical next step from there will be to starting building up – moving from chips that are almost completely 2D to fully 3D chips. When that happens, we’ll have to figure out a way to cool them. Unlike with a 2D chip, you can’t just stick a big heatsink and fan on top because it would only cool one surface, leaving the bulk of the chip to overheat. What you need is a network of cooling pipes distributed throughout the chip, almost like a biological system.

I suspect these pipes would work best if they go straight through the chip and out the other side. At small scales, fluid is very viscous and trying to turn a corner would probably slow down the flow too much. So suppose you have a cubic chip with lots of tiny pipes going in one face and coming out the opposite face. The next problem is that, if the fluid is all moving the same way, one side of the chip (the “incoming fluid” side) would get much hotter than the other. The effect could be mitigated somewhat by having some of the pipes flowing in the opposite direction. Ideally you’d want fluid coming in on all 6 faces to maximize cooling. Another possibility is pipes that split up within the chip. A wide pipe of cold fluid will have a similar effect as several smaller pipes of warmer fluid (the increase in fluid temperature is offset by the extra surface area). It would be an interesting puzzle to try to model the heat flows and come up with optimal pipe configurations. In doubling the side of the chip, one probably has to increase the proportion of chip volume dedicated to cooling by some factor 2ⁿ – I wonder what this fractal dimension is.

For most efficient cooling, one would probably want to take the cooling fluid from the CPU and any other hot parts of the system and compress it (just like the coolant in a fridge), allowing it to expand inside the CPU. Then rather than having lots of noisy fans one has one noisy compressor (which would probably be easier to acoustically isolate – maybe even by putting it outside). Fans are a big problem for noise and reliability – my main desktop machine (at the time of writing) has five of them, of which two have failed and a third is on its last legs.

Another major problem that will need to be solved is pluggable cooling lines. People expect to be able to build their own computers, which means that it must be possible to plug together a CPU, motherboard, graphics card and cooling system without an expensive machine. That means we’ll need some kind of connector for plugging the coolant lines from the CPU (and other hot components) into the cooling system. Ideally it will be easy to connect up and disconnect without the possibility of introducing dirt or air into the coolant lines, and without the possibility of coolant leaks. I suspect that whoever invents such a connector will make a lot of money.

Usually the best way to make a major change to a piece of code is to try to break it down into small changes and to keep the code working the same after each such small change. The idea being that if you make too many changes and break the code too badly, you might never get it working again. Without working code it can be difficult to figure out what the next step should be.

But sometimes, incremental changes just don’t work. In particular, if you’re making major architectural changes, trying to construct something that is 90% original architecture and 10% new architecture is going to involve just as much extra work to try to make the incompatible pieces fit. In these cases, sometimes the only thing you can do is take the whole thing to pieces and put it back together again the way you want it.

I went through quite a few design revisions to get to the pipeline architecture I described yesterday. Some ideas I tried out and then abandoned:

• Giving the filters the responsibility of keeping the data they needed.
• Filters telling other filters how many samples they should consume or produce.
• A FilterGraph object which held all the buffers and which had methods to make and break connections.
• All the reader and writer methods being on the buffers.
• Lookahead reader methods for filters.
• Filters encapsulating other filters that they communicate with.
• Having separate consume() and produce() methods.
• Having the Reader and Writer functionality as part of the Consumer and Producer classes (this introduced a surprisingly significant overhead)
• A Connection object to encapsulate the buffer.

It’s rather difficult to tell what’s going to work well and what isn’t until you actually write some code. And then it takes some trial and error work to hit upon the right pattern. Assumptions must be called into question. Prejudices must be discarded. Darlings must be killed. But you know when you’ve got it right because the rest then practically writes itself.