Category Archives: Engineering

Intel Developer Forum (IDF) and Moore

On Tuesday, 9/18/07, I attended Intel Developer Forum held at the large Moscone Center West in the beautiful San Francisco. IDF is celebrating its 10-year anniversary this year and yet I have never attended one before, perhaps due to my association with Sun. Intel is a relatively new partner to Sun and we’re ramping up the learning curve on Intel’s offerings so we can design server products around it.

I came away very impressed with Intel’s speed in execution. Looks like they have all the ducks lined up and firing on all cylinders: Penryn, Nehalem, Tolapai, and etc. The attendance was very good – around a thousand or so. The topics that stood out for me:

1. All the 3-week-old wafers that are showing off Nehalem, Tolapai, and etc. Looks like they’re working just fine. Excellent execution, Intel. Being paranoid and having a good competitor like AMD really helps to spear things along. 🙂

2. USB3: 10x the speed of USB2. It has optical and copper phy layer. This could potentially put some of the PCEe devices out of business due to the parity in performance. Of course, we may see an explosion of I/O devices that normally resides within the box. I can just picture HDTV, HD camera, high-performance storage array, and etc.

3. Mobility: WiMAX and etc. We may well be cutting out all the cables soon on PC’s.

4. I didn’t get the chance to see the show cases. I heard lots of good product offerings though.

The highlight of the day is the appearance of Gordon Moore, the originator of “Moore’s Law.” By his own account, Moore’s Law may soon hit a wall in 10 or 15 years when we may hit the physical limits of material properties. When asked about making tough decisions, he said, “Tough decisions are normally very close. You may as well toss a coin.” Dr. Moore suggested that life science may be the way to go for today’s engineers. Being in a new industry has its reward as in the in case of Gordon Moore himself. He projects that computer still needs to be able to interact with human as the next wave of computer innovation.

I felt a sense of excitement as in the early days of the computer shows. Intel is leading the effort to re-shape the computer industry. I think I’ll go back again next year.

Why do we choke?

I have been the designated tutor of my 5-year-old daughter’s piano lessons at home (my wife does the driving to/from the piano teacher). One thing I have noticed is that there would be times when she really aced one part of the song consistently then afterward she would choke or fumble hopelessly on that particular part some days later. This is not unusual for myself, and most people or even athletes (remember the disappointment we felt when we saw the ice skaters fell miserably on a simple routine?). We sometimes make mistakes where we or others least expected that we would make. Why is that? I’ll defer the scientific explanation to the brain expert. My theory is that we often choke where we haven’t experienced failures yet or we haven’t figured out how to fail. And failures are our enforcement for continuous success.

Drawing a similarity to why a hardware system would sometimes fail where it’s least expected to fail – like I2C (the “slow” system management bus) that does the housekeeping within the system, or simple power sequencing circuits involving power supplies. And the simple answer is often that we haven’t figured out how to make it fail or test to fail – whether intentionally or unintentionally.

As part of my job at Sun Microsystems – System Validation or hardware quality assurance of sorts, we need to harden/toughen our hardware and correct/catch all of the hardware bugs before we release our hardware to our customers. After the hardware goes out to the field (customers), any hardware bug could have serious financial and logistic consequences for Sun, not to mention having to answer to our Quality Office 🙂 Financial consequence entails many order of magnitude to fix the problems using field engineers or recalling the products altogether. Logistic consequences sometimes mean living with the minor hardware bugs and resulted software legacy issues when an improved hardware is phased in. It’s all risk and disaster management. The complexity can get really nasty.

So how do we prevent “choking” at all? For the computer hardware, we would need to stress each of the circuits, even the most unlikely candidates, to failure if possible. The means looking at the boundary conditions of the design and coming up with creative ways to “break” the design and check if we have sufficient design margin to weather the constant shocks of component variations, manufacturing process variations, operation condition variations and etc, during the entire product life at the customers’ site. This is whole new topic for a separate blog at a different time.

For my 5-year old daughter’s piano lessons, it means more practices and further drill down to where she shows sign of “breaking” or carelessness. Sometimes, I would make her play a certain segment of the piece in the middle to break up the routine a bit and see how she reacts to it. It’s all about making her fail before the “big” day – the May 20, 2007 recital. It’s so good to practice your theories on your children 🙂

“Contact Resistance Estimation for Time-Dependent Silicone Elastomer Matrix of Land Grid Array Socket”

After spending 7 years managing an engineering organization that designs Sun’s CPU LGA (Land Grid Array) socket, I have accumulated lots of hands-on knowledge about this LGA mechanical “beast.” It’s a “beast” because it has some interesting behaviors that are difficult to predict due to its “system” nature, encompassing the contacts, CPU package, socket frame, heatsink attach, PCB and etc. The following IEEE article that I co-authored with the scholars from CALC of University of Maryland is a good manifestation of the knowledge.

IEEE Article “Contact Resistance Estimation for Time-Dependent Silicone Elastomer Matrix of Land Grid Array Socket”