Table of Contents Previous Chapter Next Chapter

8.0 Frame Buffer Specification

27 October 1995
Revised 7 December 1995

8.1 Significant Changes in this Version

8.2 Terms

The term Buffer will refer to the Frame Buffer, an in-house designed and fabricated box used to supply test images to a Front End Processor (FEP).
The term image will mean a set of pixels as defined in a DPA/DEA Interface Control Document.
A special pixel having a Pixel Code (unused by the FEP) used exclusively by the Frame Buffer for function control.
The term file will refer to that set of data words downloaded from the DECstation to the Buffer box.
The term frame will refer to the set of data stored in the Buffer's memory. Frames include both image and directive pixels.

8.3 Initial Requirements/Specifications

The following requirements/specifications for a "Frame Buffer" box were proposed:

8.4 Basic Design Concept

The Buffer is designed around a Motorola 56001 Digital Signal Processor (DSP). All code will be in ROM. A DMA interface is incorporated for receiving downloaded files from the DECstation (and possibly DMA equipped SPARCstations). An internal memory stores a full 16 Mbit frame plus up to 128K miscellaneous pixels (e.g., Over Clocks, Ignores, directives, etc.). The memory is organized in 9 131,072 x 16-bit pages. Electrical and data format of signals interfacing to flight hardware will be reproduced as defined in the "DPA/DEA Interface Control Document". Integrated circuits interfacing to flight hardware will be commercial versions of flight components. Signal timing will be done with hardware circuitry versus software control. The Pixel Clock frequency is derived from an "RC Coupled CMOS Gate Mulitvibrator" circuit running at approximately 6.4 MHz. Since the frequency is determined by a resistor and capacitor, its stability will not be very good.

The Frame Buffer will not supply FEP power. Buffer internal power will be over-voltage protected.

Buffer requirements such as telemetering a segment of pixels "n" times, or a frame "n" times, are accomplished by using special "directive" pixels inserted in the appropriate locations in the downloaded file. These directives use five (TBR) Pixel Codes not used by the FEP. In some cases the 12 data bits in the directive or the 12 data bits in a second pixel are an argument to the directive. Directive pixels must be inserted by the user in the file to be downloaded.

8.5 Operating Modes

There are two modes of operation selected by a front panel switch: Ramp and Normal Mode.

8.5.1 Ramp Mode

In Ramp Mode the Buffer continuously telemeters pixels which are generated in real time--this is not a stored file. The ramp image begins with 4 Ignore pixels followed by 4 Vertical Syncs followed by 1024 rows of 1024 columns of Valid pixels. Column 0 of each row contains the row number (0 thru 3FF hex). Columns 1 thru 1023 contain the column number (1 thru 3FF hex). Each row ends with 32 Over Clocks having an incrementing data field (0 thru 1F hex) followed by 4 Horizontal Syncs.

8.5.2 Normal Mode

8.6 Directive Functions

In the following paragraphs, unused bits in hexadecimal fields are marked with the letter `X'.

8.6.1 "EXXX" Last Pixel Flag (LPF)

The LPF marks the last pixel in the downloaded file. The data bits in this pixel are ignored. Attempting to download pixels after a LPF will have an indeterminate effect on the Buffer operation. A frame may contain multiple images but only one LPF directive.

8.6.2 "Annn" Repeat Segment "nnn" times (RS)
"Xnnn" Segment Length argument (SL)

This function requires two arguments. The first argument is the 12 data bits in the directive which defines the number of times (up to FFF hex) the segment is to be written to the FEP. The second argument is in the following pixel and defines the number of pixels (up to FFF hex) in the segment. The pixel following the second argument is the first pixel of the segment.

8.6.3 "7nnn" Repeat Frame "nnn" times (RF)

Repeat this frame "nnn" times. If the downloaded file does not begin with this directive, or if its argument "nnn" is "000 hex", the frame will repeat continuously. This directive must appear as the first word in the downloaded file--it is only tested once, and will be ignored if it occurs later in the file.

8.6.4 "6000" Go (TBR)

This single directive (or, more appropriately, command) downloaded from the DECstation causes the Buffer to begin telemetering a currently stored frame. This directive is ignored unless a frame has been stored in the buffer.

8.7 Current Status

Two circuit boards have been wired and a third is in progress. (Hardware revision levels below are for initial use only.)

The current version of the DSP code processes directives correctly. Timing has been a concern because, within the 2.5 sec pixel period, each pixel is read, decoded and processed before it is telemetered to the FEP. "Repeat Segments" within the frame are processed in about 1.5 sec. Continuous frames are also not a problem, taking about 0.75 sec to process. The additional code required to process a "Repeat Frame" proved to be a problem. Periodically it has taken more than 2.5 sec to set up for the next frame. As a result, the last pixel of the previous frame would be re-telemetered before the first pixel of the coming frame could be latched into the output circuits. To avoid this problem, I have the DSP running with minimum wait states. To gain some margin, the current 24 MHz DSPs will be replaced with 33 MHz devices. The download time for short (1k word) files has been measured at approximately 3.2 sec/word. The requirement in which the Buffer would generate a "base" frame which would continuously telemete meter pixels which change data from one image to the next according to downloaded parameters will not be implemented.

8.8 Proposed Additional Features

8.8.1 Front Panel Status LEDs

8.8.2 Error LED(s)

Table of Contents Previous Chapter Next Chapter
Peter G. Ford
Last modified: Mon Nov 25 15:22:26 EST