Notes on front end for DisplayPort

18 views

Skip to first unread message

Mike Field

unread,

Oct 3, 2015, 4:35:27 AM10/3/15

to foss-displayport

Here are some notes I made on the frontend - at the moment my test patterns generate a valid stream in the Transceivers's clock domain.

To make it have a VGA-like interface this is what is required:

1. Count the pixel clock cycles to work out the video timings (front porch, back porch, sync width, visible width). This is needed for when the Main Stream Attributes are sent - Simple

2. Write the pixels into a 24-bit FIFO in the source clock domain, with a 48-bit read port (2 pixels at a time, as one gets routed to each DisplayPort channel). It doesn't have to be very deep (64 words at most). An extra couple of bits might be useful for signaling start and end of active video lines - should be pretty simple.

The more I think about it, the more I think about itthat data something should be written every cycle of the pixel clock, to give the DP interface all the timing information it can (as it needs to count the pixel clock cycles). Initially this could be an IP core, but would then need to be moved to primitives to keep the design completely Open Source

3. Pull the active pixel data with the correct cadence to assemble them into 64 word transmission units. This might have a few tricks, as all the TUs are supposed to have the almost the number of data words (and are then padded so that all TUs are the same size +/- 1 symbol, which must be padded to make up to 64 cycles). It gets a little bit tricky as the pixels are appearing 24 bits at a time per channel, but needs to be diced up and length-balanced on 8-bit bound for transmission, and we need to work at 135MHz, processing up to two symbols per channel per cycles - "Here be dragons"

4. Keep track of the mysterious M and N values, which are sent to the sink to recover the original clock - Sounds simple in the DP spec - use 0x80000 for N, and count pixel clock cycles.in a 19-bit counter.

5. There is a little bit of magic required in signalling the start of the horizontal blanking area while in the vertical blank area. It has to be inserted at the correct time as is pixels had been sent. This is most likely achieved by actually sending through dummy pixels, from the source clock domain, and on the output side not send the BE ("Blank End") code or the TU data. This would just leave the BS ("Blank Start") symbol in the output stream. This just got a lot easier as I typed this email.