Using the Video Port Sub System (VPSS) for Inter-Processor Communication

From Texas Instruments Embedded Processors Wiki

Contents 1 Application Description 2 Environment 3 Hardware 3.1 Daughtercard 3.2 Using the Daughtercard 3.3 Daughtercard Errata 4 Software 4.1 Software Flow 4.2 DM355 Transmitter 4.3 DM6437 Receiver 5 References 6 To Be Added

Application Description

Many Davinci technology users require a high bandwidth interface for moving information in a multi processor system, such as uncompressed video, compressed video, and general data. Typically such interfaces would include EMIF, HPI, PCI, or SRIO.

A way to add in a high bandwidth connection between Davinci processors is to utilize the VPSS. This interface is well suited to video data, and can also be used for transferring general non video data. This document will discuss interfacing two Davinci devices using their video ports, in particular this is written in regards to Davinci devices with the VPSS (VPFE/VPBE) hardware, though similar concepts can apply to other video port types.

This concept was presented at TIDC 2008, the presentation can be found at the TIDC archives.

Environment

This was implemented using a DM355 transmitter and a DM6437 receiver, the same concepts could be used on other VPSS based devices such as DM6446.

Hardware

Daughtercard

To create an interface between two Davinci EVMs a daughtercard was created, this daughtercard was designed with the following in mind:

• To be low cost and quick to create
• To be easily populated by hand
• To be flexible, supporting multiple boards
• To minimize potential noise as best possible given the above constraints

This was achieved by creating a two layer board less than 4"x4" with multiple potential population points for connectors that can be populated or left blank based on the function the board is to serve with as much ground plane fill as possible to minimize noise. The daughterboard has a unified parallel video connector that contains both receive and transmit signals, this allows a single PCB to act as a transmitter or receiver depending on how the board is populated. The board is able to be connected as a receiver or transmitter to a DM6446 EVM, DM355 EVM, or DM6437 EVM, however only DM355 transmitter and DM6437 receiver have been tested. The board also has pads to place a surface mount oscillator if the a custom generated clock is desired, however this was not used.

The schematic and layout was done using Eagle 4.16r2, the source files can be found attached to this article. The boards are not being manufactured for sale however with the source one can have the boards printed up for a relatively small cost by a PCB manufacturer.

Using the Daughtercard

The daughterboard itself is relatively easy to use, one simply populates the connectors that are necessary to interface with the EVM in question, for example for a DM355 transmitting board one needs only to populate DC5, and for the DM6437 simply populate DC_P1, note the connector names match the name of the mating connector on the EVM. In the case of the DM6437 daughtercard the connector to mount is a Samtec TFM-150-31-S-D, note that it must be this taller connector it will not be able to clear other components on the EVM. For the DM355 connector the shorter TFM-125-01-S-D works fine.

The unified parallel connector uses standard pin headers that can be found at an electronics store and a standard parallel cable, similar to an IDE cable without the key pin, and being straight through. With both daughtercards populated and mounted on their EVMs and the parallel cable connecting them the video ports of the two boards will have made the physical connection.

Daughtercard Errata

Note that in the case of the DM6437 one issue was overlooked for our use case in the daughtercard's design, that is that the DM6437 requires the TVP5146_ENABLEn signal to be pulled high to disable the on board TVP5146. If the pin is not pulled high than you could potentially have both the daughtercard and the TVP5146 driving at the same time, to avoid this a 3.3kohm resistor can be added between pins 5 and 95 of the DC_P1 connector, this can be easily modified using a small wire.

If one was to make a new revision of this it may be worth using a 4 layer board to allow for a more effective ground plane and cleaner routing. It may also be worth redesigning the unified interface that connects the daughtercards with a ground wire in between each signal wire to reduce noise, with the board as is one can get a clean signal however it requires a particularly short parallel cable and may not always be clean.

Software

This was tested using DVSDK 1.30.00.23 on DM355 and DVSDK 1.01.00.15 on DM6437, newer DVSDK/LSP versions may change how the video drivers function as well as their APIs, so using newer DVSDK software versions will require some porting effort with different modifications.

Software Flow

The general flow of the software in transferring arbitrary data over a video interface is for the transmitter to 'packetize' the data and pack it into the frame such that it can be sent like a normal video frame out of the port. On the receiving end the software must examine the frame and check to see if it contains a new packet of data, and if it does contain a new packet the software will act upon it (copy the data somewhere, run something, etc.). There are some good animated slides in the TIDC presentation that help to show this concept. This means that the interface is fairly latent (a frame delay (1/30th second) between sender sending and receiver receiving), however it has the advantage of allowing for very high bandwidth, or to work along side an existing video stream.

DM355 Transmitter

The major difference between the DM355 and DM6437 for this application is that the DM355 will be running Linux and thus using Linux video drivers which operate significantly differently from the DSP/BIOS based drivers on the DM6437. To put the DM355 in a display mode that is more suitable for transmitting arbitrary data over the video bus video=dm355fb:ooutput=ntsc:format=ycc8 should be appended to the bootargs variable within U-Boot, this tells the display driver that it should configure the VPBE/VENC for YCC8 mode which is discussed in section 2.2.2 of SPRUF72. The YCC8 mode essentially allows the VPBE to output data on the video bus that exactly matches the data that is in the video buffer in DDR, other modes can cause filtering, truncating, and synchronization problems with certain data values, with this mode only a few register tweaks are required to output proper data.

To get proper data output one must tweak a few registers in addition to setting the display driver to YCC8, this is where a small kernel modification comes into play, with a simple proc interface which takes an address and a value to write to that address added to the kernel one can change these registers from user space, which makes debugging the interface much easier, in our case the proc was called davinci_vpbe and by running a few simple commands the registers that need tweaking can be adjusted, below is a Linux script that sets up these registers.

#Format 
#echo ADDRESS THE_VALUE > /proc/davinci_vpbe 
#OSDHADV 
echo 01C7053C 0000008C > /proc/davinci_vpbe 
#HSTART 
echo 01C7041C 00000046 > /proc/davinci_vpbe 
#BASEPX 
echo 01C70240 0000008C > /proc/davinci_vpbe 
#YCCTL 
echo 01C70438 00000011 > /proc/davinci_vpbe 
#VDPRO 
echo 01C70408 00000000 > /proc/davinci_vpbe 

The first three values OSDHADV, HSTART, and BASEPX are modified to meet the equation (OSDHADV/2)+HSTART=BASE_X where BASE_X is an even value, if this is not satisfied you will still see video appearing to work, however the actual data values will come out as being averaged. YCCTL is setting the CHM and R656 bits while the VDPRO register being cleared is disabling any video filtering/processing that can be done by the VPBE.

With the driver set to YCC8 and the registers mentioned above adjusted one can start putting values into the display driver's video buffer (not the OSD) and see it come out on the bus exactly as it is inside the buffer. To facilitate exercising the interface the LCD Loopback example from dvsdk_1_30_00_23\PSP_01_20_00_004_1\examples\VPBE\Source\DLCDExample can be used, with some slight modification it can add in arbitrary data to an area of the image that can be picked up by the receiving device.

DM6437 Receiver

The DM6437 side is much easier to work with in the implementation, the raw capture example out of the box will do the majority of what is needed, no driver modification is necessary. On the DM6437 end the raw capture example from C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample\rawcapture can handle the format coming from the DM355's YCC8 mode, if you are passing through video the example must be modified to display on the VID window instead of the OSD window since the color format coming across will be YCbCr. Similar to the DM355 side, the example code can be added to with some modification to recognize arbitrary data coming from the DM355 so it can extract and act upon it.

References

For thoughts and discussion on this concept, please take a look at and post on the Davinci E2E forum.

A similar implementation can be found in TMS320DM64x Video Port to Video Port Communication.

The DM355 VPBE is discussed in detail in the DM355 VPBE Reference Guide.

The DM6437 VPFE is discussed in detail in the DM6437 VPFE Reference Guide.

To Be Added

• Source to DM355 Linux driver proc.
• Source to DM355 modified LCD display example.
• Source to DM6437 modified raw capture example.

Leave a Comment