First data's in the register, then it's not

11/10/2010 8:34 AM EST

Back in the mid-1980s, there were a few competing computer bus technology standards. The company I worked for at the time chose the VME (Versa-Module Europa) Bus, figuring that it would be a long-lived standard. Their intuition proved correct, as we still utilize that technology for certain applications today.

As part of the design team for an avionics test set project, I was called upon to design a VME Bus-based multi-purpose interface card that enabled the test set to talk to the unit under test as well as to control the external test equipment (signal generators, spectrum analyzers, etc.). This was in the era of through hole-mounted DIPs (Dual In-line Packages); Pin Grid Array packages were not very prevalent yet. That meant that processors were usually 64 pin, 800 mil-wide packages and interface controller chips were 36-48 pin, 600 mil-wide packages.

For this reason, it was unlikely that a board manufacturer would sell a CPU with the SCSI interface on board (that would come later). Since the NCR 53C80 SCSI interface chip and the SCSI terminators took up so much circuit card real estate, SCSI was usually offered as a separate card with a DMA controller and a bunch of memory. Since we were building for a ruggedized application, we designed our own card and combined functions where convenient. As I recall, the circuit card included a MIL-STD-188/114 (a variant of RS-232) interface, an IEEE-488 (also called HPIB or GPIB) interface, and a SCSI (Small Computer Systems Interface) controller for disk drive access, as well as the VME System Controller functionality (bus arbitration and system reset).

The 53C80 interface was deceptively simple as it included a bi-directional, 8-bit data bus and a few address and control lines. When we got to the point that we were testing the hardware with the software, we started having trouble reading back the data that we wrote to the device. It seemed that one moment the data was in the register, and the next, the register contained zeros. We tried doing back to back reads and got some really weird results: the data could be the desired number, zeros, or even a different number, seemingly at random.

As I discovered after thoroughly poring over the data sheet, the 53C80 has two control lines specifically set up for DMA (Direct Memory Access) controller support, to speed up large block transfers of data. This gave the system designer the option of dumping the SCSI data in shared memory and allowing the CPU to do some more important activities, while the DMA controller transferred the data to the SCSI chip. Since ours was a test system, performance was not deemed to be critical, so we chose not to implement the DMA interface.

Apparently, I should have pulled up the DMA-related inputs: DACK* (DMA acknowledge) and EOP* (End of Process). Since these lines were floating during a normal write cycle, the chip randomly processed their state as an additional DMA write, loading zeros or other random data into the registers. Four years earlier in my job as a Test Engineer, I was trying to figure out a problem we were having with a MIL-STD-1553 interface (a Manchester-encoded, 3 Mbps, serial interface – commonly used in avionics). Some brands of 1553 Transceivers would work with the Harris 1553 CODEC and some would not (no output was seen from the device).

I discovered the problem when probing the output of the CODEC. My finger touched the output enable pin and the signal came back. I even fussed out the engineer in front of the program manager for forgetting to pull up the output enable. Years later, I made the same mistake and that engineer was now my boss! Good thing he had a sense of humor. Another important lesson learned: Always read the manual thoroughly!

Author Dwight Bues is a Georgia Tech Computer Engineer with 27 years experience in Computer Hardware, Software, and Systems and Interface Design.