---

6.3  Remarks on the PCI interface

What can one say? The package - hardware device plus on-board firmware plus device driver - simply does not work as advertised at present. If it did do all the tricks in its manual reliably, there are still operations that UltraDAS needs which it does not support. This section lists the biggest problems outstanding in v1.3 of the package. No programming details are given (a) because the package comes with an adequate manual and (b) because no successful way of driving the device has yet been found.

There is no reset function in the device driver for the on-board DSP (as distinct from reset functions for the DSPs in the detector controller). If the DSP programme crashes, the board can only be recovered by pressing a physical reset switch on its back panel. This is unacceptable for a server system, although it might prove bearable in a laboratory system.

Not all crashes and hangs of the DSP programme are cleared by the board's reset switch. These errors are not cleared by rebooting the computer; the machine must be power-cycled to recover.

The large buffer on the board should allow very long latencies in reading pixels from the buffer into Unix memory. We expect to exploit this by calling read several times during a long readout and processing pixels from the first read while the next read is still in progress. This usage does not work reliably: about 1 in 10 reads for partial readouts cause pixels to be lost.

The FIFO-like behaviour of the on-board buffer is broken by a misunderstanding in the device driver. When reading in chunks of less than a full readout, the chunks are constrained to be exactly the same length as the DMA buffers in the device driver. If chunks of a different size are used, then pixels are immediately lost and the readout fails.

Unlike the S-bus interface, which made a clear distinction between local commands to the interface board and remote commands to the camera, the PCI interface confuses the two kinds of commands. Some commands to the camera seem to have side-effects in the interface, and these are not documented.

Commands into the driver are split into two classes. Native commands, which are executed as interrupts to the DSP can be given at any time. "Manual" commands, which are serviced in the DSP's main loop can only be given when the DSP is not otherwise busy. A particularly vexing case is the RDC command to the camera that invokes readout. This is a manual command (the vendors own applications do not use it, so it has second-class status), so it cannot be given while the DSP is busy waiting for pixels. However, until the DSP is ready for pixels, it is unsafe to invoke readout.

The device driver tries to hide the modal behaviour of the interface from the application. To do this, it does the mode switching automatically, as a side-effect of its commands. This arrangement causes the impasse described in the previous paragraph. In addition, to automatically switch back to message mode after readout, the interface has to be told how many pixels are expected. It requires the DAS to tell it not the total number of pixels but the sizes in x and y of a raster which has the same number of pixels as are expected; that is the PCI-interface package does not support windowing with more than one window. Window patterns that are legal in UltraDAS need not have the necessary two factors: it is possible to set a window pattern that reads out a prime number of pixels.

The interface is more abstract than that for the S-bus board, but it requires lower-level work! Instead of sending a message with a single ioctl call, several - up to six in the worst case - are needed.

In summary, the PCI package is currently unserviceable due to implementation bugs and is anyway mal-designed. The best approach for ING might be to dump the vendors firmware and device driver and to replace them with much-simplified code that emulates the S-bus interface but removes the hard-real-time constraints.