A Scalable Video Rate Camera Interface

This is a "sampler" page from the Robotics Institute of Carnegie Mellon University

The backbone architecture of the system is provided by the iWarp computer, which is an 8x8 two-dimensional torus of processors, each of which is connected to its four neighbors, as shown below.

iWarp has several features that make it suitable for this application:

1. It has sufficient bandwidth to support video rate. The bandwidth along any one of the links (arrows) in the figure above is 40 MB/s.
2. That bandwidth is reservable. It is possible to set up connections that constrain messages to be sent exclusively along a particular set of links.
3. The processors are fast enough. The iWarp processor runs at 20 Mhz and can read its memory at 10 MHz, exactly matching video rate.
4. The processor performs synchronous memory access. No data caching is employed in iWarp, so that when a memory read is executed by the processor, a read appears on the memory bus.
5. The iWarp board is extendable. Each iWarp processor has a memory interface connector available, to which other devices can be interfaced.
6. iWarp is systolic. Data can be transferred from the processor directly to the pathway without first passing through memory, greatly reducing memory bus traffic.
7. The system has enough memory. The iWarp system used here has 16 MB of memory on each of 32 of its processors, making it possible to store over 500 1 MB images.
Exploiting these features, we designed the simple interface shown below. This interface takes the analog output from four sync'ed television-quality cameras, does A/D conversion, and presents the digital value of the result as a 32-bit word in iWarp's memory space. The iWarp processor to which this board is attached reads the word and sends it systolically to the processors with the large memories where the image is stored.

Since the iWarp can do synchronous memory reads at 10 MHz, exactly matching video rate, no buffering or FIFO is necessary on the video interface. As soon as the data is available, iWarp reads it and feeds it to the pathway.

Since iWarp makes it possible to reserve pathway bandwidth, we can guarantee that the video stream will never be interrupted, even momentarily, as it proceeds from the iWarp where the data is digitized to where it is stored. This makes it unnecessary to perform buffering at the digitizing iWarp cell. This is important because doing such buffering would use memory bandwidth, making it impossible for the iWarp to keep up with the video stream.

Our current system uses just one of these video interfaces, but it is readily possible to scale it to use as many as eight, which would support 32 cameras. One architecture for such an expanded system is:

Rev. 2 8/21/94.