DisplayPort with FPGA

[hamster_nz]

A quick note - I think I've managed to get the first Open Source DisplayPort Interface running on an FPGA:

http://hamsterworks.co.nz/mediawiki/index.php/DisplayPort

[Scrts]

A quick note - I think I've managed to get the first Open Source DisplayPort Interface running on an FPGA:

http://hamsterworks.co.nz/mediawiki/index.php/DisplayPort

Nice! What resolution would be a limitation for the regular LVDS? Do you have any plans to run this on transceivers?

[hamster_nz]

A quick note - I think I've managed to get the first Open Source DisplayPort Interface running on an FPGA:

http://hamsterworks.co.nz/mediawiki/index.php/DisplayPort

Nice! What resolution would be a limitation for the regular LVDS? Do you have any plans to run this on transceivers?

At a guess, there is no resolution limitation on LVDS - you just keep making the dispay interface wider. With 4 channels active DisplayPort 1.1 can run about 540M pixels per second (in 422 mode, 24 bits per pixel), just enough for a UHD @ 60Hz I guess.

It's currently running on the transceivers.

[legacy]

I am a bit confused, can I see a schematic ?

[hamster_nz]

I am a bit confused, can I see a schematic ?

On the PCB is just sockets and coupling caps.

No Vendor IP blocks are used in the FPGA design, so all source is open.

Best my ASCII art skills allow - all running at the 135MHz TX clock (TX transmits 20 bits per cycle)

Code: [Select]



+--------------+     +--------------+
| Configuration|     | AUX Channel  |
| State        +<--->| Interface    |
| Maschine     |     |              |
+------+-------+     +----+---------+
       |                  |
       V                  V
   Internal           1Mb/s AUX Channel
   Control            to DisplayPort
   Signals            Sink (screen)


+--------------+
| Video source |
| 800x600 or   |
| 3840x2160    |
+------+-------+
       | 73 bits
       V
+------+-------+     +------+-------+
| Stream       |     | Stream       |
| Attribute    +<----+ Attribute    |
| Merge        |     | Formatting   |
+------+-------+     +------+-------+
       | 73 bits
       V
+------+-------+     +------+-------+
| Idle         |     | Idle Pattern |
| Pattern      +<----+ Generator    |
| Switch       |     |              |
+------+-------+     +------+-------+
       | 72 bits
       V
+------+-------+
| Scrambler    |
| Reset        |
| Inserter     |
+------+-------+
       | 72 bits
       +------------------+-----------------+------------------+
       | 18 bits          |                 |                  |
       V                  V                 V                  V
+------+-------+   +------+-------+  +------+-------+   +------+-------+
| Scrambler    |   | Scrambler    |  | Scrambler    |   | Scrambler    | 
+------+-------+   +------+-------+  +------+-------+   +------+-------+
       |                  |                 |                  |
       V                  V                 V                  V
+------+-------+   +------+-------+  +------+-------+   +------+-------+
| Per-Channel  |   | Per-Channel  |  | Per-Channel  |   | Per-Channel  |
| Skew Delay   |   | Skew Delay   |  | Skew Delay   |   | Skew Delay   |
+------+-------+   +------+-------+  +------+-------+   +------+-------+
       |                  |                 |                  |
       V                  V                 V                  V
+------+-------+   +------+-------+  +------+-------+   +------+-------+
| Training     |   | Training     |  | Training     |   | Training     |
| Pattern      |   | Pattern      |  | Pattern      |   | Pattern      |
| Switch       |   | Switch       |  | Switch       |   | Switch       |
+------+-------+   +------+-------+  +------+-------+   +------+-------+
       |                  |                 |                  |
       V                  V                 V                  V
+------+-------+   +------+-------+  +------+-------+   +------+-------+
| 8b/10b       |   | 8b/10b       |  | 8b/10b       |   | 8b/10b       |
| Encoder      |   | Encoder      |  | Encoder      |   | Encoder      |
+------+-------+   +------+-------+  +------+-------+   +------+-------+
       | 20 bits          |                 |                  |
       V                  V                 V                  V
+------+-------+   +------+-------+  +------+-------+   +------+-------+
| 2.7Gb/s  TX  |   | 2.7Gb/s  TX  |  | 2.7Gb/s  TX  |   | 2.7Gb/s  TX  |
| with swing & |   | with swing & |  | with swing & |   | with swing & |
| Pre-emphasis |   | Pre-emphasis |  | Pre-emphasis |   | Pre-emphasis |
| Control      |   | Control      |  | Control      |   | Control      |
+------+-------+   +------+-------+  +------+-------+   +------+-------+
       |                  |                 |                  |
       V                  V                 V                  V
            High speed serial outputs to the DisplayPort sink


[bson]

Cool project!  Do you think a Zynq 7015 could drive DisplayLink using GTP transceivers?  If so I might pick up a 7015 board...

[marshallh]

Nice job, I know just how non-trivial this is.
There is a Lattice reference design (I tihnk for the ECP3) you can check out, it has lots of documentation you may find useful, as well as most of the implementation.

[legacy]

i'd like to interface a few big LCDs grabbed from laptops, currently I am playing with my Spartan6E fpga around a little STN-LCD, 320x240x2 (2bit of color), there is no LVDS, and the signal integrity is not critical.

[Scrts]

A quick note - I think I've managed to get the first Open Source DisplayPort Interface running on an FPGA:

http://hamsterworks.co.nz/mediawiki/index.php/DisplayPort

Nice! What resolution would be a limitation for the regular LVDS? Do you have any plans to run this on transceivers?

At a guess, there is no resolution limitation on LVDS - you just keep making the dispay interface wider. With 4 channels active DisplayPort 1.1 can run about 540M pixels per second (in 422 mode, 24 bits per pixel), just enough for a UHD @ 60Hz I guess.

It's currently running on the transceivers.

Oh that's cool. I thought it's running on regular LVDS at 800x600p60.
I wonder if there's a huge difference in DP and eDP. The latter one should be a strip-down version.

[hamster_nz]

I just have to gloat a little - 2160p achieved!



It is running in 'only' YCbCr, 422 but that is the best a miniDP port can do!

[Rasz]

Oh man, you are powering thru those advanced fpga projects like a Champion, I love your wiki!

There is only two other free digital video fpga projects worth mentioning I know of: https://github.com/charcole/NeoGeoHDMI hdmi with audio implementation on a super cheap ($15!!) chinese Cyclone II dev board and timvideos hdmi2usb(on huge and expensive fpga).


BTW have you ever looked into MIPI? 6of9 from rPee/Broadcom recently did something wonderful and opened up MIPI CSI2 port on the Pee. 2(4 on dimm module) 1GBps lines accessible from userspace. Opens up plethora of possibilities - you can either pump data directly into Video encoder(Pee = $25 1080p/30 h264 encoder with ethernet port), or to your userspace programs (oscilloscope/logic analyser etc). There is also a parallel almost 4Gbit port on the Pee (DPM, used for video). All this makes Pee similar to Bunnie/xobs Novena laptop (2Gbit link between SoC and spartan6).

[Scrts]

MIPI CSI2 is difficult to do, because the standard is difficult to get... I didn't find any recent pdfs even in chinaweb.

[hamster_nz]

I have had a look at MIPI briefly when work were trying to get an MIPI LCD panel working. It looked like a really noisy single ended signal, but it is some weird hybrid of single ended and differential signalling. The pixel data are sent running in high speed mode, and then during the quite time the pairs act as single ended control signals (some seemed to be carrying H and V sync. It looks ugly!

http://www.xilinx.com/support/documentation/application_notes/xapp894-d-phy-solutions.pdf has some notes on it.

[Scrts]

You must also consider that MIPI CSI is for Camera and MIPI DSI is for Display. I think there was a DSI spec leaked somewhere and I also saw DSI implementation on Spartan6 somewhere too.

[bktemp]

Mike has reverse engineered the MIPI protocoll for iPod Nano 6 TFTs:
http://electricstuff.co.uk/nanohack.html

There is also this implementation:
https://hackaday.io/project/364-mipi-dsi-display-shieldhdmi-adapter

The iPod TFT uses the command mode, the other implementation the video mode.

The MIPI Phy and data packet transmission are standardized, also some basic commands, but the actual command set depends on the display manufacturer, especially for displays using the command mode and larger displays that are not covered in the specifications. There are some large diplays (2560x1600) where 4 MIPI lanes are not enough. They use 2 x 4 MIPI lanes in parallel. It took me a long time to figure this out how to get this working.

Transmitting MIPI is quite easy to implement. Most displays only need to receive data. Bidirectional communication is much more difficult.
The easiest solution for driving a MIPI LCD ist probably to get a SSD2828, because it handles all the low level MIPI stuff and it is cheaply available from china.

[Rasz]

Oh wow, didnt expect so much feedback to my mention of MIPI

Here is a preliminary mipi csi2 spec: http://electronix.ru/forum/index.php?act=Attach&type=post&id=67362

Lattice offers free mipi d-phy, and complete CSI2 sink/source implementations(docs,source,test benches, everything) for xo2(cheap tqfp available), xo3l and epc5 (ridiculously small bga, unsuitable for hobby use)

http://www.latticesemi.com/csi2rx
http://www.latticesemi.com/csi2tx

For the Pee we wouldnt need LP bidirectional BS, just a straight HS source pumping packets of bytes. I thought it was worth mentioning CSI2 port on Pee is completely open now(received data is simply dumped into memory buffer in userspace), because its not often you get a $25 SoC dev board with 2/4Gbit of input bandwidth (and ~4Gbit of output in a form of raw 24bit parallel DPI port). I am wondering what would be the cheapest way of pumping ADC data into pee at ~2GBps.

@bktemp Yes, I totally forgot about hackaday iphone hdmi2dsi shield :/ What is amazing about that project is it should be straight forward adapting it into 1080p/30 HDMI - to - CSI2 Pee bridge using one of the $35 chinese XC6SLX9 dev boards. $60 for a complete fullhd hdmi networked h264 streaming grabber.

[mikeselectricstuff]

A lot of the MIPI specs are at http://wenku.baidu.com/ e.g. search "CSI2 specification"
It is possible to get PDFs by paying a small fee, but you may need to know a little Chinese to navigate..

[bktemp]

All the MIPI PDFs can be found here under mipi (it is not mine, I found it when looking for the MIPI specs):
http://svn.hexatux.org/listing.php?repname=datasheets&

One trap that took me days was to understand how multiple lanes work:
Accorting to the MIPI phy protocol it is possible to enable the highspeed mode for each lange individually. But that does not work. You must use all the available lanes when transferring data using the highspeed mode. And there were also some commands that needed to be sent in LP mode. Now the MIPI interface is running fine using 8 lanes at 800Mbits/s each to drive a 2560x1600 display.

@mike
Your MIPI packet examples helped me much understanding how to create packets and calculate the crc. Your measurements showing real world signals were much more helpful than the waveforms shown in the MIPI specifications.
Thank you very much for your great work in reverse engineering the MIPI interface and describing everything how you replicated the driving circuit using a FPGA! 

[futaris]

BTW have you ever looked into MIPI? 6of9 from rPee/Broadcom recently did something wonderful and opened up MIPI CSI2 port on the Pee. 2(4 on dimm module) 1GBps lines accessible from userspace.

https://www.raspberrypi.org/forums/viewtopic.php?t=109137

Thanks for posting that. I hadn't seen the post on the raspberry pi forums.