Microsoft is not alone in chip woes

...in the IBM PC Technical Manual. You couldn't just go and replicate them bit-for-bit, of course — IBM jealously guarded its copyright. But you could make your own with a high degree of confidence that they worked as described in the book.

One of the key parts of the equation was the expansion bus, the signals that fed interface cards such as the graphics adaptors, disk interfaces and network devices such as our own. That became known as the ISA — Industry Standard Architecture — and its expanded variant, the EISA bus. On the surface, this looked like a perfectly normal chunk of engineering: all the signals, their timings and voltage levels, were described with lots of nice clean graphs in the Technical Manual.

Unfortunately, that was the only place you'd see lots of nice clean graphs. Reality is far messier. Signals were late or early, voltages were never quite what you'd expect, and everything could change depending on what else was plugged into the bus alongside your bit. And, of course, all those hundreds of different makes of PC had different variations. If you designed something to the book, chances are it wouldn't work very well. Experienced designers know this, and are very conservative in what they expect. Our designer was certainly experienced, and had done a good job of the ISA interface part of the chip. Our e-beam litho prototypes worked perfectly well. It had to be something to do with the Asic.

In the end, after months of extreme pain, cost and pizza overdose, the problem was revealed in a chance conversation at a conference in a "Oh, we had that problem..." way. One of the abiding sins of the ISA bus — indeed, any bus that used the rather simple-minded signalling circuitry of the time — is called undershoot. If you rapidly change a signal at one end of the bus from five volts to zero volts, you would expect it to stop at zero all the way along the bus — it's just a bit of wire. But a combination of factors to do with basic physics means that further down the bus, some of the energy in that transition drives the voltage past zero, into negative numbers.

This is very bad news. The transistors in the logic circuits can lock up or even get permanently damaged by even a slight negative input. From time immemorial, chip designers have guarded against this by clamp diodes, fast-acting switches on the input lines that turn on as soon as a negative voltage appears and effectively short-circuits it to zero. Imagine a horde of Vikings rampaging towards a richly appointed town: the clamp diodes are trapdoors that open under the feet of the naughty Nordics and funnel them off to a big underground pit.

Normally, this just works. A negative spike appears, the clamp diodes turn on and the energy flows through them to ground. Nobody sees a thing. But on the Asics we were using, 'ground' wasn't quite as good as it should have been. If a really large undershoot happened on lots of input lines simultaneously — something that happened only when a certain data pattern appeared on the bus, and then only on particular designs — then the diodes turned on fine but the energy so diverted couldn't get back onto the main bus fast enough. The result was that the whole chip then went negative. The pits full of Vikings overfilled and burst up through the floors of the townsfolk.

It's an analogue quirk in a digital device, and not one that was specified in the design guide for the Asic — which, after all, was being driven way outside its nominal specification. We fixed it, if memory serves, by adding an extra bus interface chip between the Asic and the PC; this soaked up the undershoot without complaining and we moved onto the next design.

How could we have avoided this? As a small company, we couldn't afford the time or the money to go out and buy every make of PC before launch and go through the saturation testing which would have revealed the problem — but that's an issue that still plagues even the biggest outfits. We got our design right. The only thing that might have saved us was if we'd been far better plugged into the experiences of other companies working at the same problems; in those pre-internet days, that was by no means a simple job for a 10-person outfit in a converted warehouse in the East End of London.

As it was, we learned a great deal the hard way. It happens. It didn't cost us a billion dollars or earn us scalding headlines; we got off lighter than Microsoft's Red Ring Of Death. The complexity of modern IT, especially when you factor in millions of users and all their variations, is such that you can't know everything in advance. The world is not as it appears in technical manuals, marketing slides or engineers' heads — and all you can do is learn as much about it as you can before making the leap of adding to it.