AVA200 Firmware and Associated Control Protocol

  Since the hardware only contains a single digital video chipset, and a single audio codec, only one physical input may be used at a time. When using ``gen-locked'' video sources, it is possible to multiplex the digitising hardware on a per-frame basis. For audio this is clearly not sensible. The firmware therefore supports multiple concurrent video streams, and a single outgoing audio stream.

For each video stream it is necessary to download a number of parameters to the unit. These parameters specify picture sizes and scaling, pixel formats, data rates, the physical video channel to use and the VPI/VCI for the outgoing video stream. This information is loaded into a ``Video Bucket''. Similarly, parameters for the audio streams including sample rate, format and physical audio input must be loaded into an ``Audio Bucket''.

A ``Schedule'' is then loaded into the AVA200 which specifies a sequence of video buckets. This schedule is executed in a round-robin fashion, grabbing a frame using the parameters specified in the relevant video bucket. Thre reserved video bucket index of zero indicates that the unit should idle for a frame. The schedule also identifies which audio bucket should be used.

  
Figure 4: AVA200 Video Programming Paradigm.

These datastructures are shown diagrammatically in Figure 4. The figure illustrates two concurrent streams whose parameters are specified in Video Buckets VB1 and VB2. The first stream is being allocated 3 frames out of every , and the second is receiving 2 frames out of every . The remaining frames are being spent idling. Bucket VB3 has been loaded with the parameters for a third stream in preparation for an atomic change of schedule.

  
Figure 5: AVA200 Audio Programming Paradigm.

The audio paramters for each codec are selected from one of a number of Audio Buckets (see Figure 5). Since the AVA200 has only one codec, only the bucket referenced by channel A0 is examined. Audio buckets may also be loaded in advance (e.g AB1) in preparation for an atomic change of configuration.

The AVA200 uses AAL5 for all network I/O, although this may not be the case for the DAN implementation as the reliable nature of communications across the DAN remove the need for the added complexity of AAL5. Video formats used on the DAN may also take account of the unique properties of the Desk Area Network.

The AAL5 CRC32 field is not checked by the MPU on receive however, due to the complexity, so a simpler 16-bit checksum is used. The AAL5 CRC32 field is correctly generated for all transmitted PDUs however.

The receive side of the AVA200 control protocol consists entirely of single cell (52/53 byte) AAL5 PDUs. This is to remove the need for complicated reassembly functions on board the unit. The same format is used for both requests and acknowlegements.

Generic Control Cell Format

Within this AAL5 PDU are various fields which are common to all control cells. A generic AVA200 control cell is structured as shown in Figure 6.

  
Figure 6: AVA200 Generic Protocol Cell.

The offsets of the fields within a cell are summarised in Table 1.

  
Table 1: Generic Protocol Cell Field Offsets

The various fields are described below:

• SEQUENCE - If these four octets match those in the previous cell then this cell is treated as a duplicate of the previous cell. Duplicates will be acknowleged without any further action.
• OPCODE field identifies the type of the control cell as shown in Table 2. The most significant bit of the opcode field is set if the cell is an acknowlegement cell.
• CHECKSUM contains two octets which represent a simple 16 bit checksum of the previous 38 octets. Although the entire block is protected by the AAL5 checksum, this is too expensive to compute with the limited processing power available on the unit, and a simpler error detection mechanism was therefore required. The checksum consists of the sum modulo of the previous 38 octets XORed with . The most significant octet is first.

  
Table 2: Protocol Cell Opcodes

Reset Cell Format

Sending a RESET cell to the AVA200 will cause all subsystems of the unit to be reinitialized. The management VPI/VCI for all future communications is specified in the cell. The acknowlegement for the cell contains version information for the hardware and firmware. The AVA200 RESET cell is structured as shown in Figure 7.

  
Figure 7: AVA200 Reset Cell and Acknowlegement.

The various fields in the RESET cell are described below:

• FRB - Fabric route byte (1 octet). This field is only examined if the AVA-200 is connected directly to a switch fabric.
• PCRB - Port Controller route byte (1 octet). This field is only examined if the AVA-200 is connected directly to a switch fabric.
• MGMT. HEADER - ATM Header for the management stream (4 octets).

• VENDOR - Contains an ASCII string identifying the vendor.
• DEVICE - Contains an ASCII string identifying the device.
• DEVICE REV MAJOR and DEVICE REV MINOR identify the revision number of the unit.
• FIRMWARE REV MAJOR and FIRMWARE REV MINOR identify the revision number of firmware installed in the unit.

Ping Cell Format

Sending a PING cell to the AVA200 will cause the cell to be acknowleged without any further action. This is useful for checking the reachability and state of the unit. The acknowlegement for a ping request contains the same data as the request cell. The AVA200 PING cell is structured as shown in Figure 8.

  
Figure 8: AVA200 Ping Cell and Acknowlegement.

Video Load Cell Format

Sending a VIDEO cell to the AVA200 enables the loading of per-stream configuration into one of the 16 available buckets. The AVA200 VIDEO cell is structured as shown in Figure 9.

  
Figure 9: AVA200 Video Load Cell and Acknowlegement.

The offsets of the fields within the Video Bucket are summarised in Table 3.

  
Table 3: Video Bucket Data Offsets

The INDEX field identifies which bucket is to be loaded. Only the least significant four bits are examined. The format of the configuration data to be loaded into the bucket is shown in Figure 10.

  
Figure 10: AVA200 Video Data.

The video data consists of:

• FRB - Fabric route byte. This field is only examined if the AVA-200 is connected directly to a switch fabric.
• PCRB - Port Controller route byte. This field is only examined if the AVA-200 is connected directly to a switch fabric.
• STREAM HEADER - ATM Header for the video stream.
• CONTROL REGS - Register values for the control logic as shown in Figure 16.
• SCALER REGS - Register values for the Digital Video Scaler (Philips SAA7186). For more information see Figure 14
• DECODER REGS - Register values for the Digital Multistandard Decoder (Philips SAA7191). For more information see Figure 11
• SEQUENCE - Contains the initial video frame sequence number. If the first octet of the sequence number is non-zero then the sequence number is loaded from the bucket number it specifies.
• KEEPALIVE - Contains the initial number of video frames to transmit before keepalive messages are required. Some early units do not support the keepalive feature.

  
Figure 11: Decoder Registers.

Decoder Registers

The fields in the Decoder registers have the following effects:

• INPUT selects one of the 3 inputs.
• SVHS should be set when an SVHS input is being used i.e. Separate luminance and chrominance information. Without this bit set, only the luminance information will used and the picture will appear monochrome.

Scaler Registers

The fields in the Scaler registers have the following effects:

• FIELD selects whether to grab odd fields only, even fields only or both as follows:

  00

  Reserved.

  01

  Both fields for non-interlaced storage.

  10

  Odd fields only for non-interlaced storage.

  11

  Even fields only for non-interlaced storage.

• FORMAT selects the format of the pixel data supplied by the front end from one of those shown in Figure 12. Note that the bus is 24 bits wide, and so for YUV 4:2:2 the U and V components alternate between odd and even pixels.

  01

  16 bit YUV 4:2:2

  10

  24 bit RGB 8:8:8

    
  Figure 12: Pixel Formats output by the Scaler.
  

• XD sets the pixel width of the output from the scaler.
• XS sets the pixel width of the input to the scaler.
• XO sets the horizontal pixel offset of the input to the scaler.
• YD sets the pixel height of the output from the scaler.
• YS sets the pixel height of the input to the scaler.
• YO sets the vertical pixel offset of the input to the scaler.

  
Figure 13: AVA Video Stream Sampling/Scaling

  
Figure 14: Scaler Registers.

Control Registers

The fields in the control registers have the following effects:

• MODE selects the packing of the pixel data into the output bytes as shown in Figure 15. The input bytes may be 24 bit RGB 8:8:8 with the red component in byte zero, or 16 bit YUV 4:2:2 with the Y component in byte zero.

  00

  8:8:8 RGB or 16 bit YUV depending on output of the scaler.

  01

  5:5:5 RGB

  10

  3:3:2 RGB

  11

  5:5:5 BGR

• COUNT selects the number of bytes transmitted per pixel.

  00

  1 byte per pixel e.g. 3:3:2 RGB or 8 bit mono.

  01

  2 bytes per pixel e.g. 5:5:5 RGB or 16 bit YUV.

  10

  3 bytes per pixel e.g. 8:8:8 RGB.

  11

  4 bytes per pixel e.g. 8:8:8 RGB with a zero fourth byte.

• END reverses the order of the pixel bytes. e.g. 0123 3210. This can be used to adjust the order of Red, Green and Blue components to match the destination framestore.
• RATE controls the transmission rate for the pixel data. The small gap between transmission of each PDU is proportional to this value. The value must therefore vary with the size of PDU in order to maintain the same sustained transmission rate.
• XTILES sets the width of the frame in tiles.
• COUNT sets the number of PDUs per frame.
• PACK sets the number of 8x8 pixel tiles packed into each AAL5 PDU.
• LENGTH MSB sets the MSB of the AAL5 Length field in each tile.
• LENGTH LSB sets the LSB of the AAL5 Length field in each tile.
• TIMEOUT sets the timeout for grabbing each video frame in units of 4ms. This is used to prevent the unit from locking up when presented with a poor video signal.

  
Figure: Effect of the MODE bits on the output pixel format. Input format is set by the Scaler

  
Figure 16: Control Registers.

Audio Load Cell Format

Sending an AUDIO cell to the AVA200 enables the loading of a new audio configuration. The data field of the AVA200 AUDIO cell is structured as shown in Figure 17.

  
Figure 17: AVA200 Audio Load Cell.

The offsets of the fields within the Audio Bucket are summarised in Table 4.

  
Table 4: Audio Bucket Data Offsets

The INDEX field identifies which audio bucket is to be loaded. The AUDIO DATA field consists of:

• FRB - Fabric route byte (1 octet). This field is only examined if the AVA-200 is connected directly to a switch fabric.
• PCRB - Port Controller route byte (1 octet). This field is only examined if the AVA-200 is connected directly to a switch fabric.
• STREAM HEADER - ATM Header for the audio stream (4 octets).
• LENGTH - sets the length field of the AAL5 PDU.
• CODEC REGS - Register values for the audio codec (Analog Devices AD1848) as shown in Figure 19 (16 octets).
• SEQUENCE - Contains the initial audio sequence number (4 octets).
• KEEPALIVE - Sets an initial number of audio PDUs to be transmitted.

  
Figure 18: AVA200 Audio data.

  
Figure 19: Audio Codec Registers.

  
Table 5: Audio Sample Rates

Codec Registers

The fields in the Codec registers have the following effects:

• SOURCE selects the input from which to capture.
• MIC adds and extra of gain to the MIC input channel.
• GAIN sets the gain of the input in .
• MUTE silences a channel.
• ATTEN sets the attenuation of a channel in .
• 8/16 selects either 8 or 16 bit samples.
• LIN/#TEX2HTML_WRAP1338# turns on companding.
• MO/ST turns on stereo.
• RATE selects the sampling rate as shown in Table 5.
• XTAL selects the oscillator to use.
• CHAN selects whether the left or right channel appears first in the PDU.
• END causes the MSB of a 16-bit audio sample to precede the LSB in the PDU.
• DMIX turns on digital mixing of the capture data with the playback data within the chip.
• LENGTH sets the length field of the AAL5 PDU.
• SAMPLES specifies the number of samples per AAL5 PDU.

Schedule Load Cell Format

Sending a SCHEDULE cell to the AVA200 causes the audio and video schedules of the unit to be updated to those specified in the cell. The AVA200 SCHEDULE cell is structured as shown in Figure 20.

  
Figure 20: AVA200 Schedule Load Cell and Acknowlegement.

• LENGTH specifies the number of four bit bucket indices in the video schedule.
• VIDEO specifies up to 60 bucket indices for the video schedule. The most significant four bits of each octet precede the least significant four bits in the video schedule as shown in Figure 21. The reserved video bucket index of zero indicates an idle frame.
• AUDIO sets the audio buckets to be used for up to four audio streams. Currently the unit only supports a single audio stream controlled by A0. Audio bucket indices should be less than 4.

  
Figure 21: AVA200 Schedule Data.

Synchronisation Stream Format

At the end of every shceduling period (defined by the length field of the SCHEDULE cell), the AVA-200 sends a synchronisation PDU on the management VPI/VCI. This PDU contains the current sequence numbers of all video and audio buckets. The fields in the SYNC PDU are as shown Figure 22.

  
Figure 22: AVA200 Synchronisation PDU.

• VIDEO SEQUENCE field contains the sequence numbers of each of the 16 video buckets. These are stored as 32-bit big-endian unsigned integers.
• AUDIO SEQUENCE field contains the sequence numbers of each of the 4 audio buckets. These are stored as 32-bit big-endian unsigned integers.

This feature is not present on some early versions of the unit.