Pathfinding at a technology company can be considered a form of research—research on an explicit engineering problem. Often it can be a long way off before the problem really needs to be solved. Sometimes it’s quite by accident that a solution developed for one problem solves a similar problem further down the roadmap. In this three-part series I tell engineering stories around testing an I/O circuit without explicit testing from the Automatic Test Equipment (ATE.) As is the case with most pathfinding work, the engineers experimented on solutions with a particular product yet it didn’t get used in production.
An I/O leakage test covered not only a verification of an I/O specification; it provided an indicator of manufacturing process health, both wafer production and assembly of die into a package. This parameter also provided insight into potential reliability failures. The traditional test tri-states the circuitry– basically turns off the circuits to leave the I/O pin in a high impedance state. Next, a voltage is applied by the ATE pin electronics card (PEC) and the resulting current is measured. Typically, the distribution of measured current can be at least one to two orders of magnitude smaller than the specification. So, given the multiple items this test is covering, the test limit applied is tighter than the actual specification. The pathfinding challenge: test I/O leakage when the tester can’t touch the pins.
The challenge of leakage no-touch testing had made an early appearance in a Pentium II microprocessor product, code-name: Deschutes. The microprocessor had a back-side bus that connected the microprocessor to a memory chip. In the Pentium Pro version, the chips connected within a shared package. In the Pentium II, a small system board included the memory and microprocessor that would be inserted into the computer. To increase functional coverage, the test engineering team explored testing Deschutes with a memory chip on the ATE load board. Hence, the ATE could not connect to the Deschutes backside bus and I/O leakage test would still be required.
Tawfik Arabi, the lead test engineer, made an astute observation. He could use basic electrical circuitry principles to measure the pin leakage in an alternative manner. The concept:
- Set a voltage level on a pin
- Tristate (i.e. disconnect the pin from a driving source)
- Let it discharge
In the presence of excessive leakage, the pin would discharge faster. He called it AC Leakage test. With the inherent capacitance of the pin and leakage modeled as R he could simulate the expected time to discharge. The concept could even be applied to Pin to Pin leakage, which looks for defects that inadvertently connect two isolated pins.
Alternative test methods typically focus on finding defects, which opens up possibilities that a “Is it a good circuit?” thinking doesn’t offer. As described earlier with Weak Write Test Mode, we shortened the test time by deliberately but weakly writing the opposite state into a memory cell. Tawfik’s technique considered measuring in a different domain: current in amperes became time in milliseconds. The technique had such potential in cost saving benefits and enabling new products that initially Intel reserved it as a trade secret. A couple of years later the patent was awarded and the idea was shared in an external paper.
The initial exploratory work done on the Deschutes Backside bus had data on ~ 1000 units to show that it worked. Due to change in product test plans, the team discontinued the manufacturing validation portion of the project. The engineers published their work at an internal conference called Design Test Technology Conference.
Pathfinding work is like that: you take it to a certain point, then write up what you have so that others may continue when the challenge reappears. Engineers at Intel kept taking up this challenge and it took many tries before a manufacturing test was fully enabled in an Intel product. Stay tuned for more stories on testing leakage with no pins.
Have a productive day,
Dear Reader, What memory or question does this piece spark in you? Have you started the work on a solution only to have it put aside because the project was shelved/canceled? Did you leverage pathfinding work from a previous engineering team? Please share your comments or stories below. You, too, can write for the Engineers’ Daughter- See Contribute for more information.