Author Topic: DisplayPort in Verilog.  (Read 5839 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

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1832
  • 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.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4344
  • 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: 1531
  • Country: dk
 
The following users thanked this post: kony, mark03, Nitrousoxide, BrianHG

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1832
  • 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?
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1832
  • 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: 3707
  • 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 »
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4344
  • 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.
 

Online OwO

  • Frequent Contributor
  • **
  • Posts: 653
  • 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

Online mark03

  • Frequent Contributor
  • **
  • Posts: 575
  • 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.
 

Offline 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.
 

Offline 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

Offline 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: 3287
  • 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