DisplayPort in Verilog.

[hamster_nz]

Today I did a bit of playing around calculating the effective video pixel clock, when you pack a given number of pixels into a DisplayPort "Transfer Unit". A TU is block of 32 to 64 bytes, packed with pixel data and padding bytes. I guess that the ideas the use of TUs limits the depth of the FIFO required in the receiving DisplayPort sink, because a 64-byte the FIFO should be all you need.

It turns out that if you pack 11 pixels (33 bytes) into a 40 byte transfer unit it gives an effective pixel clock of 74.25 MHz (for one lane) or 148.5 MHz (for two lanes) and 297 MHz (when using four lanes). This is perfect for implementing standards-compliant 720p @ 60Hz, 1080p @ 60Hz and 2080p@30Hz, depending on how many lanes you chose to use.

Although blinding obvious in retrospect, it was hidden because DP is a complex spec with so much flexibility that it is hard to see the easiest implementation path. This is really neat because you don't have to rely on variable size TU packing, splitting pixels between TUs or generating 'fractions of a pixel' numbers within the data stream.

The upshot being that the Github project now includes a single-lane 720p colour bar test pattern, and should have a dual-lane 1080p one tomorrow (time willing).

In case somebody walking the same path finds themselves here I've attached a screen grab of my spreadsheet to this post. Yes, I know that this is not quite XKCD '.norm' format, but it is pretty close  - (https://xkcd.com/2116/).

[asmi]

Yea, DP spec is not the best one of those I read. I found especially hilarious that despite the protocol being modern packet-based, the actual data stream is still old school with dead bands and stuff - which comes all the way from analog video signal and CRT tubes Have you looked at streaming audio together with video? I never really got around to making my HDMI TX capable of sending audio as well.

[hamster_nz]

A quick update. I have an 'Aha!' moment, and got 720p with a 74.25MHz dot clock working in a few hours. Overjoyed with this I then spent a week trying to get 1080p to work, including writing a few bits of code to parse simulation output, and looking through 4.5M+ lines of output hoping to find an unknown error, where none existed.

With a little bit of help from a user on Reddit, I got the two magic numbers I needed to get 1080p colourbars.

Yay! 720p and 1080p!

I now should go back and rewrite quite a bit to make it look less hacky...

[hamster_nz]

Wanted to distract myself last night, so I added a 3840x2160@30Hz, YCC 422 test stream to the project....

[BrianHG]

If Verilog is C then SystemVerilog is C++. Yes it does solve a lot of the problems and gives you more syntactic sugar which leads to more readable code, but it does so by adding a shit ton of complexity and also brings all the legacy crap from verilog with it. You can still easily shoot yourself in the foot in SV just like you can easily have subtle buffer overflow bugs in C++. I still use VHDL for new projects and if there is a module where the very limited type system of VHDL limits me then code generation is probably what I would go for. Last company I worked at had to resort to code generation even on a SystemVerilog project.

Not sure what complexity you're talking about. It makes things so much easier all way around. Interfaces alone is a killer feature as one no longer has to type all those buses' wires over and over and over again, and when used in combination with modports makes designer's intent even clearer, removing all language clutter that just hides what's actually going on. This is especially so with AXI interfaces as they have a lot of signals in the bus, so if you have several AXI ports - you would need to have several pages worth of signals. This is bad enough in Verilog, but in VHDL it's a total nightmare if you have to route some of those buses internally to some other submodules - you'll have a ton of code that doesn't need to be there yet stupid VHDL forces you to have it. There is no reason whatsoever to use that ancient language anymore. SV is superior in any way, shape or form. Its only problem is limited support in some toolchains, but this is getting better with every passing day.

I find such comments about VHDLs strictness helping coding over System Verilog a non-issue.  Write your code properly and cleanly and you will have no problems with System Verilog while enjoying a lot of it's simplifications.  Just don't engineer stupidly and you can create a project of any scope and size without issue.  If you need a specific compiler to force you to code in a specific way to prevent bad programming practices, maybe this shouldn't be a classification of that compiler's engineering environment quality.

[smartprotox]

Hello sir,

We try to connect the display port via  Nexys video through your code.

But unfortunately we haven't get the display port output.

Can you please help me to solve the issue?

Thank you!

[betocool]

@hamster_nz, are you referring to Symbiflow when you talk about the "open source FPGA masterplan"?

Cheers,

Alberto

[hamster_nz]

Hello sir,

We try to connect the display port via  Nexys video through your code.

But unfortunately we haven't get the display port output.

Can you please help me to solve the issue?

Thank you!

Hi, sorry, this project was may years ago and most of my memory of the fine details are very vague. It would take an hour to set the board up, build a bitstream and so on, and I am pretty sure it will work just like last time.

I would recommend that you try the 800x600 datastream, with a single DisplayPort lane, and see if that works. Because of the clock rates playing well with the link rate this is the most reliable display (it doesn't involve fractional clock recovery).

If that doesn't work, it will require debugging of the AUX channel to see why the monitor can't sync to the data stream. Without access to your hardware I can't do that - it will need a logic analyzer to see what is going on, to see where the monitor and DP source don't agree.

[SiliconWizard]

I've toyed with the idea of using DP for transferring any data, so I'm interested. Has anyone implemented something in VHDL? I think hamster_nz may have, but IIRC, his web site is now down?

Standard DP is one-way only if I'm not mistaken, just like HDMI (except for an aux data channel, with a relatively low-speed 1Mbps), but one could likely implement a bidirectional link with it with some modifications in the protocol.

There are 4 lanes if I'm not mistaken, so one could use 1 or 2 for each direction. It's just some musing - at this point, I guess there wouldn't be much left of DP except for the connectors. I admit I quite like the mini-DP connectors.

[hamster_nz]

DisplayPort is
- The data lanes (running 8b10b encoding)
- The AUX channel (a wrapped up I2C like interface) that allows you to find capabilities and stand up the links.

The protocol clearly has a "source" and "sink" as part of the design, with the source very much in control of configuring the sink (e.g. rate selection, link training, equalization and so on) through configuring registers over the AUX channel.

[SiliconWizard]

The protocol clearly has a "source" and "sink" as part of the design,

Yes, in the same vein as USB-C.
But can a given device, from the standard, flow data in both directions through the data lanes? Which was my point. (If so, good.)

But as I said, it's just a musing - for a general-purpose data link, trying to be compliant with DisplayPort probably makes little sense, and all that would be left would be the physical link and 8b/10b encoding, really.

[hamster_nz]

But can a given device, from the standard, flow data in both directions through the data lanes? Which was my point. (If so, good.)

The high speed lanes are TX on the source, RX on the sink. So, nope, not suited to bi-directional data flow.