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

0 Members and 1 Guest are viewing this topic.

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
DisplayPort in Verilog.
« on: February 24, 2019, 08:29:03 pm »
I've had my arm slightly twisted by a few Verilog usering friend, and have implemented DisplayPort in Verilog.
 
It is completely free of vendor IP, but of course uses vendor specific primitives for the transceiver blocks. It also 'CPU/software free' using only state machines to stand up the data lanes, keeping everything in the HDL domain.

Currently it only uses a single 2.7Gb/s lane (of the four in each DP cable) to display 24-bit 800x600, but already most of the code pipeline is good for all four lanes. To enable four lanes I just have to convert a few test streams and the code to lay out the main stream attributes depending on the number of active lanes. 
 
https://github.com/hamsternz/DisplayPort_Verilog

As I was till now mostly a VHDL user the code will be extra verbose and clunky - sorry about that. I really need to sit down with a good Verilog user and be shown the right way to do things...
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: TiN, pigtwo, ebclr, agehall, Wiljan, BrianHG, asmi, tsman

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #1 on: February 24, 2019, 09:01:44 pm »
Did you feel it was easier to write in Verilog than VHDL?
 
The following users thanked this post: agehall

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #2 on: February 24, 2019, 10:36:15 pm »
Did you feel it was easier to write in Verilog than VHDL?

"Easier to write, harder to write correctly" pretty much sums it up. Debugging is much the same.

For me it is far more likely that poorly written code will actually build and need debugging. I can see why Verilog is likened to assembler - code has about the same likelihood of building but no working.  :D

For example, I had a typo like   "reg [7:0] whatever; whatever <= data[15:0];" when I meant "whatever <= data[15:8];". In VHDL it would barf at compile time with a size mismatch, in Verilog it gives a low priority warning.

Also shot myself a few times with "whatever <= "00";" vs "whatever <= 2'b00;". I miss a type safe language

I also find like 'initial' blocks clunky, preferring to have starting values assigned to signals where they are declared. But I guess it will encourage me to use sync reset signals rather than relying on initial values.

But I am sure I could get used to it...

Oh, and forget "x <= a & b;"  when I meant " x <= { a, b };"
« Last Edit: February 24, 2019, 10:38:08 pm by hamster_nz »
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, NorthGuy

Offline ehughes

  • Frequent Contributor
  • **
  • Posts: 364
  • Country: us
Re: DisplayPort in Verilog.
« Reply #3 on: February 25, 2019, 12:57:39 am »
Quote
I also find like 'initial' blocks clunky, preferring to have starting values assigned to signals where they are declared. But I guess it will encourage me to use sync reset signals rather than relying on initial values.

XST/Vivado allows you to just assign the initial value (with a blocking assignment)

reg [7:0] Test = 8'b10101010;


You can also do it in the declaration of the port (Verilog 2001 and SystemVerilog)

module Cnt (input Clk,
output reg [7:0] Q = 8'b101010101);


I only use initial block for simulation test benches to setup the test run.

Quote
be shown the right way to do things.
But I guess it will encourage me to use sync reset signals rather than relying on initial values.


Think about propagation of the synchronous reset throughout the chip in a complex FPGA design.   I have actually observed this cause serious problems with timing closure with global signals that rarely change become the primary impediment to achieving a clock rate.
  There is a good argument to not use global reset (and only local ones)   

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf



« Last Edit: February 25, 2019, 12:59:47 am by ehughes »
 
The following users thanked this post: Someone

Offline KE5FX

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: us
    • KE5FX.COM
Re: DisplayPort in Verilog.
« Reply #4 on: February 25, 2019, 01:18:35 am »
Great.  How hard do your friends have to twist your arm to build a JESD204B interface?  ;D
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #5 on: February 25, 2019, 01:33:09 am »
Quote
I also find like 'initial' blocks clunky, preferring to have starting values assigned to signals where they are declared. But I guess it will encourage me to use sync reset signals rather than relying on initial values.

XST/Vivado allows you to just assign the initial value (with a blocking assignment)

reg [7:0] Test = 8'b10101010;


You can also do it in the declaration of the port (Verilog 2001 and SystemVerilog)

module Cnt (input Clk,
output reg [7:0] Q = 8'b101010101);


I only use initial block for simulation test benches to setup the test run.

Quote
be shown the right way to do things.
But I guess it will encourage me to use sync reset signals rather than relying on initial values.


Think about propagation of the synchronous reset throughout the chip in a complex FPGA design.   I have actually observed this cause serious problems with timing closure with global signals that rarely change become the primary impediment to achieving a clock rate.
  There is a good argument to not use global reset (and only local ones)   

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf
I thought I had issues with "multiple assignments" if I assigned where it was declared and then assigned it in an 'always' block, but I could be mistaken. Heck, I am sure I am mistaken because I trust that you know Verilog far better than I do!

I too try to avoid using global resets in FPGA designs as much as possible, but if I don't have initial blocks I end up with "X"s everywhere during simulations. For example, in this project I have to replace every 512th "Blank Start" symbol with a "Scrambler Reset" symbol, so have a 9-bit counter and look for it rolling over.
I don't care about the initial value of this 9-bit counter, but unless it is given one it stays at "all Xs" forever, making the simulation and h/w not match. Mismatches are bad, so at least for now I am working with an "initialize every reg" mindset.

Anyhow, all the code is a bit crufty because it isn't suppose to be the best or optimal implementation, just one that works and I can follow the code back to the protocol spec and debug in bite-sized chunks. Hopefully it will improve over time.



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 hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #6 on: February 25, 2019, 01:38:58 am »
A high-spec RF front-end with a JESD204B interface would be enough twisting...  ;D

Just had a look at http://www.ti.com/lit/ml/slap161/slap161.pdf, and heck it looks a lot like DisplayPort's data path. 8b/10b, multiple lanes, wouldn't be surprised if there isn't an I2C interface that is used to bring up the link (like DP's AUXCH).
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 ehughes

  • Frequent Contributor
  • **
  • Posts: 364
  • Country: us
Re: DisplayPort in Verilog.
« Reply #7 on: February 25, 2019, 02:11:11 am »
Quote
I thought I had issues with "multiple assignments" if I assigned where it was declared and then assigned it in an 'always' block, but I could be mistaken. Heck, I am sure I am mistaken because I trust that you know Verilog far better than I do!

Let me know if you get an error.        There will probably be synthesis errors if you do another blocking assignment in an always block (inferring combination logic).   Shouldn't be an issue with a non-block assignment for combination logic.

If you get time and use Vivado, look into SystemVerilog.   It has some features from VHDL but retains some of the simplicity of Verilog.

Quote
I too try to avoid using global resets in FPGA designs as much as possible, but if I don't have initial blocks I end up with "X"s everywhere during simulations. For example, in this project I have to replace every 512th "Blank Start" symbol with a "Scrambler Reset" symbol, so have a 9-bit counter and look for it rolling over.
I don't care about the initial value of this 9-bit counter, but unless it is given one it stays at "all Xs" forever, making the simulation and h/w not match. Mismatches are bad, so at least for now I am working with an "initialize every reg" mindset.


If you want to looked any any register in simulation,  you must initialize it.  per the Verilog spec,  all registesr start as "unknown".   Unforunately,  you have to initialize anything you want to monitor.  It just becomes a habit. 

You can also initialize internal registers from you simulation test bench.  Let's say your module call "Foo" in your test bench has an internal reg "Bar".        You might instantiate it in your test bench like this:

Code: [Select]
reg ClkIn = 0;
wire [7:0] OutputMonitor;

Foo U1 (.Clk(ClkIn), .Output(OutputMonitor));

In your simulation you can access the internal reg "Bar":

Code: [Select]
initial
begin

U1.Bar = 8'b101010101;

end

It is very useful for monitoring internal junk.     


Speaking of "internal" simulation with Verilog...   This trick I saw in the Picoblaze design using //synthesis translate_off   //synthesis translate_on  directives.    You can create a "fake" string that only exists in simulation to overlay on your output diagram:   


Code: [Select]
//This is useful for simulation purposes
//synthesis translate_off
reg [16*8-1:0] StateString;
always @(*)
begin
    case(CurrentState)
   
    `WAIT_FOR_BTN0: StateString = "WAIT_FOR_BTN0";
    `WAIT_FOR_BTN1: StateString = "WAIT_FOR_BTN1";
    `WAIT_FOR_BTN2: StateString = "WAIT_FOR_BTN2";
    `WAIT_FOR_BTN3: StateString = "WAIT_FOR_BTN3";
    `COUNT:         StateString = "COUNT";
     default:       StateString = "Unknown";
   
    endcase
end
//synthesis translate_on
endmodule


You could access this string from your simulation as U1.StateString

 

I haven't been doing FPGA for awhile and miss it now...    Raw State machines and processing pipelines really get me interested!  None of this Python and Javascript shit.

Nice work on getting the DisplayPort up and running.   I may have to work that in the course I teach.  We do experiments w/ VGA but it is getting harder for students to get access to monitors with a VGA port!




 
The following users thanked this post: hamster_nz

Offline KE5FX

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: us
    • KE5FX.COM
Re: DisplayPort in Verilog.
« Reply #8 on: February 25, 2019, 02:26:45 am »
A high-spec RF front-end with a JESD204B interface would be enough twisting...  ;D

Just had a look at http://www.ti.com/lit/ml/slap161/slap161.pdf, and heck it looks a lot like DisplayPort's data path. 8b/10b, multiple lanes, wouldn't be surprised if there isn't an I2C interface that is used to bring up the link (like DP's AUXCH).

Yep, that's what I was thinking -- I looked at your Github page and recognized a lot of JESD-isms.  There does seem to be quite a few similar features.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4341
  • Country: ch
Re: DisplayPort in Verilog.
« Reply #9 on: February 25, 2019, 07:28:48 am »
why verilog? why not vhdl?
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 1524
  • Country: dk
 
The following users thanked this post: kony, mark03, Nitrousoxide, BrianHG

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #11 on: February 25, 2019, 03:11:52 pm »
Just had a look at http://www.ti.com/lit/ml/slap161/slap161.pdf, and heck it looks a lot like DisplayPort's data path. 8b/10b, multiple lanes, wouldn't be surprised if there isn't an I2C interface that is used to bring up the link (like DP's AUXCH).

Artix-7 transceivers have built-in 8b/10b and up to 6.6 Gbit/s speed.  I don't think they're fast enough for JESD204B.

Kintex-7 can do 12.5 Gbit/s. Is this fast enough for full-color 4K?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 1831
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #12 on: February 25, 2019, 03:29:45 pm »
"Easier to write, harder to write correctly" pretty much sums it up. Debugging is much the same.

Thank you. When I look at Verilog I always@ think that it would be easier to write ... but I am too lazy to try :(
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 3687
  • Country: fr
Re: DisplayPort in Verilog.
« Reply #13 on: February 25, 2019, 04:02:36 pm »
I've had my arm slightly twisted by a few Verilog usering friend, and have implemented DisplayPort in Verilog.

Although learning new things is always good, that still saddens me.
 ::)
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: DisplayPort in Verilog.
« Reply #14 on: February 25, 2019, 05:24:34 pm »
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4341
  • Country: ch
Re: DisplayPort in Verilog.
« Reply #15 on: February 25, 2019, 06:04:41 pm »
LOL  :-DD

or the wrong keyboard  ;D
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #16 on: February 25, 2019, 10:05:48 pm »
Artix-7 transceivers have built-in 8b/10b and up to 6.6 Gbit/s speed.  I don't think they're fast enough for JESD204B.

Kintex-7 can do 12.5 Gbit/s. Is this fast enough for full-color 4K?

I have had 4K 422 YCC running on 2-lane DisplayPort for a while, but only at 30Hz , as my 4k monitor seems to have some funky compressed video timing mode that allows it to work over two lanes. (gives a 265MHz pixel clock, rather than the 297MHz that 4k 30Hz should have)

With the full four lanes 444 RGB @ 30Hz is fine with the standard video timing, and maybe 422 @ 60Hz would be possible with non-standard timings.

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 hamster_nz

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: nz
Re: DisplayPort in Verilog.
« Reply #17 on: February 25, 2019, 10:48:55 pm »
why verilog? why not vhdl?

It is a small part of somebody's master plan to make Free/Open Source FPGA tools for FPGAs from many vendors. Having a basic DisplayPort design that uses the high speed transceivers without using any IP blocks gives some additional reasons for people to work on supporting the transceiver blocks, because they have a use-case that is somewhat of value.

In the FOSS land  Verilog is perceived as the minimum viable product for a practical HDL, and as such being treated as the FPGA equivalent of assembler for a lot of tools - e.g. Your SoC builder will emit a Verilog codebase for your design (much the same way that Vendor IP wizards do now).
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 #18 on: February 26, 2019, 01:54:52 am »
Kintex-7 can do 12.5 Gbit/s. Is this fast enough for full-color 4K?
You've gotta read DS182 very carefully, as different packages and speed grades have different max MGT data rates. It's a bit easier for Artix as there the only variable is speed grade - through for some packages there are restrictions on use of neighbouring pins when MGTs are used at maximum data rate.
Also this table tells that you need only 12.54 Gbit/s for 4k@60Hz, so it's achievable with Artix speed grade 2 and 3 GTPs over 4 lane DP connection.
« Last Edit: February 26, 2019, 02:34:34 pm by asmi »
 

Offline apblog

  • Regular Contributor
  • *
  • Posts: 93
  • Country: us
Re: DisplayPort in Verilog.
« Reply #19 on: February 28, 2019, 11:20:39 pm »
Neat project.  I have learned a lot from the code you posted in the past.

I've always thought that VHDL was fundamentally better than Verilog, because it is so strict with what you write.  It's far better to catch errors early.  I find that this approach really boosts my productivity on large, complex projects.

I wish we could have the best of all worlds.  Compact syntax, strong typing, and good abstraction support, all in one HDL language.
 

Offline asmi

  • Frequent Contributor
  • **
  • Posts: 828
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #20 on: March 01, 2019, 12:28:28 am »
I wish we could have the best of all worlds.  Compact syntax, strong typing, and good abstraction support, all in one HDL language.
We do have it. It's called SystemVerilog.
 

Offline OwO

  • Frequent Contributor
  • **
  • Posts: 652
  • Country: cn
  • RF Engineer @ OwOComm. Discord: スメグマ#2236
Re: DisplayPort in Verilog.
« Reply #21 on: March 01, 2019, 03:11:59 am »
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.
Discord: スメグマ#2236
Email: OwOwOwOwO123@outlook.com
GitHub: gabriel-tenma-white
 

Offline asmi

  • Frequent Contributor
  • **
  • Posts: 828
  • Country: ca
Re: DisplayPort in Verilog.
« Reply #22 on: March 01, 2019, 03:01:35 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.
 

Offline KE5FX

  • Super Contributor
  • ***
  • Posts: 1084
  • Country: us
    • KE5FX.COM
Re: DisplayPort in Verilog.
« Reply #23 on: March 01, 2019, 04:16:50 pm »
I don't know that it's productive to turn Mike's (generous) contribution into a religious war between followers of defective gods.  Fact is, if you are going to spend much time working with FPGAs in your hobby or career, you will eventually have to come to terms with all three major HDL dialects and probably some we haven't seen yet.  Like the toolchains themselves, they all do the same thing under the hood, and they all suck, and no software people would put up with them for five minutes, and yet the suckage is frankly a small price to pay for the power you get in return.

I usually use Verilog, but one advantage to VHDL is that its prolixity makes it fairly easy to translate into Verilog, while the reverse isn't as true.  I haven't seen any automated Verilog-to-VHDL tools like vhd2vl -- has anyone else?
 
The following users thanked this post: TiN

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 573
  • Country: us
Re: DisplayPort in Verilog.
« Reply #24 on: March 01, 2019, 04:48:08 pm »
What's the best route nowadays for someone wanting to learn SystemVerilog "from scratch," i.e. not coming from another HDL, or having only a passing familiarity with HDL concepts?  It was hard enough trying to find a decent, synthesis-focused Verilog text, and now that I've dipped my toes in with a couple of easy projects, perhaps I should make the switch to SV.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf