EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: hamster_nz 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...
-
Did you feel it was easier to write in Verilog than VHDL?
-
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 };"
-
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.
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 (https://www.xilinx.com/support/documentation/white_papers/wp272.pdf)
-
Great. How hard do your friends have to twist your arm to build a JESD204B interface? ;D
-
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.
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 (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.
-
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, (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).
-
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.
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:
reg ClkIn = 0;
wire [7:0] OutputMonitor;
Foo U1 (.Clk(ClkIn), .Output(OutputMonitor));
In your simulation you can access the internal reg "Bar":
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:
//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!
-
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, (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.
-
why verilog? why not vhdl?
-
why verilog? why not vhdl?
https://en.wikipedia.org/wiki/Carpal_tunnel_syndrome ;)
-
Just had a look at http://www.ti.com/lit/ml/slap161/slap161.pdf, (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?
-
"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 :(
-
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.
::)
-
why verilog? why not vhdl?
https://en.wikipedia.org/wiki/Carpal_tunnel_syndrome ;)
If that's the problem, you're using the wrong editor :)
-
LOL :-DD
or the wrong keyboard ;D
-
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.
-
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).
-
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 (https://en.wikipedia.org/wiki/DisplayPort#Resolution_and_refresh_frequency_limits) 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.
-
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.
-
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.
-
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.
-
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 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 (https://github.com/ldoolitt/vhd2vl)-- has anyone else?
-
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.
-
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/).
-
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.
-
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...
-
Wanted to distract myself last night, so I added a 3840x2160@30Hz, YCC 422 test stream to the project....
-
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.
-
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!
-
@hamster_nz, are you referring to Symbiflow when you talk about the "open source FPGA masterplan"?
Cheers,
Alberto
-
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.
-
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.
-
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.
-
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.
-
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.