Author Topic: DisplayPort in Verilog.  (Read 5846 times)

0 Members and 1 Guest are viewing this topic.

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #25 on: March 02, 2019, 10:54:40 am »
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  :D - (https://xkcd.com/2116/).
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline asmi

  • Frequent Contributor
  • **
  • Posts: 828
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #26 on: March 02, 2019, 05:35:28 pm »
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 :-DD 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.
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #27 on: March 09, 2019, 04:44:00 am »
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...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: agehall

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #28 on: March 16, 2019, 03:45:02 am »
Wanted to distract myself last night, so I added a 3840x2160@30Hz, YCC 422 test stream to the project....
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: agehall

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3297
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #29 on: March 18, 2019, 10:39:54 pm »
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.
« Last Edit: March 18, 2019, 10:44:20 pm by BrianHG »
__________
BrianHG.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf