I had approximately 500 Pentium (P54CS) parts that uniquely failed the Weak Write Test Mode (WWTM.) In the lab I ran the test on an IMS debug tester to diagnose the failing cell location–engineers always want more data. I talked to engineering managers regarding additional tests. The resulting list would require help from other engineering teams, as they had the equipment and test programs.
A Quality and Reliability (QR) manager, Stanford Miller, suggested I look for changes in behavior due to life-time stresses. The process of life-stressing a part consists of accelerating aging of electronics via elevated voltage and temperature factors while the transistors toggle. Dubbed Burn-In, most manufacturing test processes include it to discard infant mortality failures. In this experiment the parts would be stressed for 20, 50 hours, etc. Next, these parts would be tested to look for any change in response. I went to Nancy, QR planner, to ask about setting this up. She grumbled a bit about this being an unusual request; indicating that it would be a burden. I said “I need your team’s help.”
She stared me in the eye and stated “Only if you write a memo to the team thanking them for their work.” A fair request—it pointed out that saying thank you, in writing, has value.
The experiment was conducted and no startling results occurred.
The reliability aspects of these failures had been checked, now on to quality: a system test would exercise the part in a computer. This relatively new test module was part of the P54CS test flow but obviously the failing parts had not seen this test. Another QR manager, Mike Rodgers, suggested this system test. Again, another engineering group to approach and ask for help to run ~500 failing parts through their test setup. By now I knew the routine of asking for help and expressing thanks. This experiment had results—13 parts from the sample failed the system level test, a definite quality improvement. What about the other 500 parts? Well, system level test was not a complete test. I intend to explain more in a future episode from this saga.
Via discussing with other engineers and managers, I learned about an engineer looking at running the traditional pause test at a lower voltage. I traveled to Intel’s Santa Clara campus to meet the engineer. The Stanford-educated, Nigerian-born engineer agreed to run the WWTM parts through her test setup. Then she stated, “You need to give me credit for the data I generate.” Another fair request, though this does not always happen. Her data showed that 26% of the WWTM fails would be covered by this enhanced pause test. In every presentation I gave and in the final report her name appeared.
No engineer is an island; indeed, no engineering team is an island. There exist many dependencies upon others to get the job done. In this story my focus was to gather as much data as possible about these unique failures. I learned along the way that “please” and “thank you” are powerful words and more so when you put it in writing. I also learned a lesson in data etiquette: always give attributions to others’ work that supports your engineering results.
Have a productive day,
Anne Meixner
Dear Reader, What memory or question does this piece spark in you? Have you provided data/service to another engineer or have you asked for their data/service? How did you go about attributing or were you attributed? Please share your comments or stories below. You, too, can write for the Engineers’ Daughter–See Contribute for more information.
On LinkedIn received the following comment from Valencia de la Vega “So true: “No engineer is an island; indeed, no engineering team is an island.” Teamwork, teamwork, teamwork!!!”