An old PAL saves the day
|View as PDF |
Early in my career, I worked for a defense contractor that made one-of-a-kind state-of-the-art systems. The contractor did the system design in-house, but outside contractors made many of the subsystem components per our specifications. My job on one such team was to integrate the status and control of one subsystem with the main system so that the two worked in harmony.
We lacked the luxuries that most take for granted today. Storage scopes were usually limited to two traces, and the storage was by means of a persistent screen phosphor. The scope captured and displayed slow signals better than fast signals; very fast signals sometimes required several repeated triggers to show any stored display at all.
PAL (programmable-array logic) was relatively new at the time, and tools to program these devices were crude. We could do a lot with a PAL device, but reducing the Boolean equations of the design to fit into the PAL was left to the circuit designer's wit. The designers also used a fuse map to convert the reduced equations into PAL object code to create the finished logic design. They manually entered the finished PAL code into the programmer so it could burn the fuses into the PAL. These PALs were OTP (one-time-programmable) devices, so it was a painstaking and difficult-to-verify process with the crude instruments available at the time. Much of the design effort involved being careful and hoping for the best when we had integrated everything.
| Read more |
Tales from the Cube
When a design didn't work, we discarded the device. I remember plugging my PAL, which took weeks of effort to create, into the system and watching in disappointment as the system responded in a seemingly random fashion. How could this be? I had been so careful.
I rechecked all my equations, fuse maps, and PAL code but could find no errors. I used the crude storage scope on a few critical signals, but they seemed to be completely random. It acted as if one of the status signals was doing the opposite of what it was supposed to do. Did I invert one of the signals by mistake? I rechecked again and found that I had not. Did the vendor of the subsystem invert the signal? There was only one way to find out: I changed the PAL code to invert the signal in question. I burned another device and tried again.
This time, to my surprise and delight, the system responded flawlessly. Because this was a one-of-a-kind system and because there was no time to return the subsystem for repair, management decided to leave well enough alone and shipped the final system as it was.
About a year or so later, management called upon me to help debug a system that had come back for repair. Much had happened in the meantime, and I hardly recognized the system I was asked to help with. The problem was that the controller was acting erratically. I got out the old schematics and started to look at the interface signals. The activity looked vaguely familiar. It seemed chaotic and random.
On a hunch, I went back to my desk and looked through my junk box. I was relieved to find that what I was looking for was still there, stuck in a piece of conductive foam: my original PAL that didn't work because one status signal was inverted. I replaced the PAL in the system with that old PAL and voilà! Problem solved.
It turned out that when the customer returned the system for repairs, one of the problems was with the subsystem that my PAL interfaced with. External contractors had originally manufactured that subsystem, and the customers returned it to the vendor for repair. Someone there apparently noticed what the original people hadn't and corrected the inverted signal according to specification.