Author Topic: What HDL to start with  (Read 16369 times)

0 Members and 1 Guest are viewing this topic.

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: What HDL to start with
« Reply #100 on: April 07, 2020, 06:57:13 pm »
.
« Last Edit: August 19, 2022, 03:47:15 pm by emece67 »
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9931
  • Country: us
Re: What HDL to start with
« Reply #101 on: April 08, 2020, 07:36:55 pm »
It's a little bit newer (a year or so) but COBOL is still kicking around in the banking world.  Due to a scarcity of new programmers, I imagine the old-timers are paid very well.

Not only is COBOL kicking around, it is used for Unemployment Insurance in New Jersey (and several other states) and they don't have enough programmers to keep up with the increased demand for benefits:

https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-jersey-trnd/index.html

You would have thought this stuff would have been recoded into PL/I or something.  I wonder what language is preferred for banking and business applications?  I hope the list doesn't include C++, JAVA, Python or any of the other Johnny-Come-Lately languages but it's a world of programming I don't know anything about.

BTW:  They would probably have better luck finding Fortran programmers.


 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2812
  • Country: nz
Re: What HDL to start with
« Reply #102 on: April 08, 2020, 09:30:33 pm »
It's a little bit newer (a year or so) but COBOL is still kicking around in the banking world.  Due to a scarcity of new programmers, I imagine the old-timers are paid very well.

Not only is COBOL kicking around, it is used for Unemployment Insurance in New Jersey (and several other states) and they don't have enough programmers to keep up with the increased demand for benefits:

https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-jersey-trnd/index.html

You would have thought this stuff would have been recoded into PL/I or something.  I wonder what language is preferred for banking and business applications?  I hope the list doesn't include C++, JAVA, Python or any of the other Johnny-Come-Lately languages but it's a world of programming I don't know anything about.

BTW:  They would probably have better luck finding Fortran programmers.

I now think of COBOL as the perfect example of a domain specific language. The way the datatypes are defined in the user's problem space is great. Useless for general computing but perfect for financial business systems.
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 mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: What HDL to start with
« Reply #103 on: April 09, 2020, 02:03:27 pm »
As to "modport", I don't know what it is. I've just taken a look at this: https://verificationguide.com/systemverilog/systemverilog-modport/
which was only moderately helpful. I'm under the impression we get the same thing with in/out/inout qualifiers in port declarations in VHDL, but I'm sure I'm missing the subtlety of "modport"...

The example in the asic-world link I gave is a bit more clear IMO.
http://www.asic-world.com/systemverilog/interface3.html#Modports

Or maybe you read that as well and thought is was sub-moderately helpful. Not sure, my crystal ball is in the shop.

Record in VHDL are great to get a large number of related signals through several layers of a design. Saves a lot of typing and renaming if you want to add/delete/change a signal.
Yeah, that's the feature that was sorely lacking in Ye Olde Verilog. So finally they decided to steal the idea, clean it up, give it a bit of polish and stuff it into SystemVerilog under the guise of interface.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15246
  • Country: fr
Re: What HDL to start with
« Reply #104 on: April 09, 2020, 02:15:56 pm »
As to "modport", I don't know what it is. I've just taken a look at this: https://verificationguide.com/systemverilog/systemverilog-modport/
which was only moderately helpful. I'm under the impression we get the same thing with in/out/inout qualifiers in port declarations in VHDL, but I'm sure I'm missing the subtlety of "modport"...

The example in the asic-world link I gave is a bit more clear IMO.
http://www.asic-world.com/systemverilog/interface3.html#Modports

OK, that makes the use case clearer indeed.
I'm still not convinced that modport is a good idea though at this point, at least compared to what we already have in VHDL and if the feature is indeed similar to what's going to be in VHDL-2019. I'll have to look that up if I can find any more info on that.

 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2794
  • Country: ca
Re: What HDL to start with
« Reply #105 on: April 09, 2020, 03:13:44 pm »
Here is a real-life example (I'm sure any more-or-less experienced designer will recognize the bus):
Code: [Select]
//  Interface: axi4_lite_intf
//
interface axi4_lite_intf #(
    parameter DATA_WIDTH = 32,
    parameter ADDRESS_WIDTH = 32
    );

    //read address channel
    logic [ADDRESS_WIDTH-1:0]   araddr;
    logic [`AXI4_MM_PROT-1:0]   arprot;
    logic                       arvalid;
    logic                       arready;

    //read data channel
    logic [DATA_WIDTH-1:0]      rdata;
    logic [`AXI4_MM_RESP-1:0]   rresp;
    logic                       rvalid;
    logic                       rready;

    //write address channel
    logic [ADDRESS_WIDTH-1:0]   awaddr;
    logic [`AXI4_MM_PROT-1:0]   awprot;
    logic                       awvalid;
    logic                       awready;

    //write data channel
    logic [DATA_WIDTH-1:0]      wdata;
    logic [DATA_WIDTH/8-1:0]    wstrb;
    logic                       wvalid;
    logic                       wready;

    //write response channel
    logic [`AXI4_MM_RESP-1:0]   bresp;
    logic                       bvalid;
    logic                       bready;

    modport slave(  input araddr, arprot, arvalid,
                    rready,
                    awaddr, awprot, awvalid,
                    wdata, wstrb, wvalid,
                    bready,
                    output arready,
                    rdata, rresp, rvalid,
                    awready,
                    wready,
                    bresp, bvalid);

    modport master( output araddr, arprot, arvalid,
                    rready,
                    awaddr, awprot, awvalid,
                    wdata, wstrb, wvalid,
                    bready,
                    input arready,
                    rdata, rresp, rvalid,
                    awready,
                    wready,
                    bresp, bvalid);
   
endinterface: axi4_lite_intf
Here is a module declaration using that interface:
Code: [Select]
module gpio #(
    parameter ADDR_WIDTH = 64,
    parameter DATA_WIDTH = 64,
    parameter GPIO0_WIDTH = 6,
    parameter GPIO1_WIDTH = 4
)(
    input clk,
    input axi_areset,
    axi4_lite_intf.slave bus,
    output [GPIO0_WIDTH-1:0] gpio0_pins,
    output [GPIO1_WIDTH-1:0] gpio1_pins
);
And here is instantiation of that module:
Code: [Select]
axi4_lite_intf #(.ADDRESS_WIDTH(ADDR_WIDTH), .DATA_WIDTH(DATA_WIDTH)) periph_bus();
//<....>
gpio #(
    .ADDR_WIDTH(ADDR_WIDTH),
    .DATA_WIDTH(DATA_WIDTH)
) gpio_inst(
    .clk(clk_periph),
    .axi_areset(axi_areset),
    .bus(periph_bus),
    .gpio0_pins(gpio0_pins),
    .gpio1_pins(gpio1_pins)
);

Imagine what the code would look like if all interface wires will be declared individually :-DD This radically reduces the amount of noise in the code, and so dramatically improves readability.
Modports define direction of a wire (input or output), and also make it clear which side of the bus (master or slave) the module expects to be connected to. Of course there can be more than two modports - imagine a control bus which connects to a control module on one end, and to all slave modules will have their own modports. This makes it clear which wire goes to which module, also adding new signals is trivial - you declare it in the interface and in required modports, and there is no need to make any other changes in the wiring up. So modports provide a level of abstraction above wires, kinda like interfaces in Vivado's IPI (you can think of interface as a cable, and modports as connectors on the ends of this cable). This makes working with large buses (like AXI) MUCH easier because there is much less noise from all individual wires' declarations. Just think about how many wires would you have to deal with in typical peripheral interconnect with a dozen of AXI peripherals and few masters (like CPU cores, DMA modules)!! |O
« Last Edit: April 09, 2020, 04:17:22 pm by asmi »
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9931
  • Country: us
Re: What HDL to start with
« Reply #106 on: April 09, 2020, 03:25:31 pm »
It's a little bit newer (a year or so) but COBOL is still kicking around in the banking world.  Due to a scarcity of new programmers, I imagine the old-timers are paid very well.

Not only is COBOL kicking around, it is used for Unemployment Insurance in New Jersey (and several other states) and they don't have enough programmers to keep up with the increased demand for benefits:

https://www.cnn.com/2020/04/08/business/coronavirus-cobol-programmers-new-jersey-trnd/index.html

You would have thought this stuff would have been recoded into PL/I or something.  I wonder what language is preferred for banking and business applications?  I hope the list doesn't include C++, JAVA, Python or any of the other Johnny-Come-Lately languages but it's a world of programming I don't know anything about.

BTW:  They would probably have better luck finding Fortran programmers.

I now think of COBOL as the perfect example of a domain specific language. The way the datatypes are defined in the user's problem space is great. Useless for general computing but perfect for financial business systems.

I would add Fortran to the list of ideal domain specific languages.  Maybe not the jazzed up current incantations but certainly some of the earlier versions.  I'm just starting with F77 and F90 and I like some of the changes from Fortran IV and I'll just evade the ones I don't like.

I think that when a language lasts for 50 years, the designers did something right.

I feel the same way about VHDL.  I like its verbosity, I like the strict type checking and I'm glad I started with VHDL rather than Verilog.

Like all language wars, there won't be a consensus.  So, to each their own!

I don't know why the COBOL statement MOVE CORRESPONDING caught my fancy way back when but it is the one thing I remember about the language.  Talk about a Unit Record approach...

 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: What HDL to start with
« Reply #107 on: April 09, 2020, 03:48:06 pm »
I'm still not convinced that modport is a good idea though at this point, at least compared to what we already have in VHDL and if the feature is indeed similar to what's going to be in VHDL-2019. I'll have to look that up if I can find any more info on that.
Well, if the VHDL-2019 version is how emece67 described it, then I would say "no they are not the same". Because emece67 mentioned the VHDL flavor fixes the port directionality upon instantiation. In Systemverilog this is already declared in the interface definition itself. See the previous example, that has the 3 different system, memory and tb modport declarations INSIDE of the original interface definition. So before you even decide to instantiate anything you declare 3 different "flavors" of the same interface, for use in 3 different use cases. The practical difference being, that with the modports inside the interface definition, you have a single location where you define the interface and the intended use cases. So no direction modifications inside some other file three design levels down.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20505
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #108 on: April 09, 2020, 04:02:01 pm »
I don't know why the COBOL statement MOVE CORRESPONDING caught my fancy way back when but it is the one thing I remember about the language.  Talk about a Unit Record approach...

In school I read about COBOL while learning Algol. I remember three thigs:
  • typical statement was ADD A TO B GIVING C
  • advanced use was COMPUTE C=A+B (can't really remember if the "compute" was there)
  • vowing never to program in COBOL, and never regretting it in almost 50 years :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: What HDL to start with
« Reply #109 on: April 09, 2020, 05:32:30 pm »
Imagine what the code would look like if all interface wires will be declared individually :-DD This radically reduces the amount of noise in the code, and so dramatically improves readability.

I don't need to imagine it -- I have exactly that same sub-optimal thing in my current design. It started out simple (as all things do, I suppose), and as features were added, the entity that manages setting operational registers has gotten unwieldy. So today's plan is to simplify all of it and make the registers into a record. This plan wasn't spurred on by this thread. I don't think, anyway ...
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: What HDL to start with
« Reply #110 on: April 09, 2020, 07:36:50 pm »
.
« Last Edit: August 19, 2022, 03:47:27 pm by emece67 »
 
The following users thanked this post: mrflibble, SiliconWizard

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9931
  • Country: us
Re: What HDL to start with
« Reply #111 on: April 10, 2020, 02:17:49 pm »
This idea of using a record with views could be quite handy.  I have a DMA controller with several devices connected.  Some devices are readers, some are writers and some are bi-directional yet all have the same set of signals with the only real difference being whether the device is requesting a read or a write.  There is also a memory-to-memory channel for placing the cold start loader in RAM at startup.

If nothing else, the record/view concept would add a certain amount of uniformity to the interface.

Then there are the 4 identical serial ports (these should be easy) which are, themselves, connected to the DMA controller.  I could use a generic to specify the baud rate.

One of these days I'm going to clean up that project.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15246
  • Country: fr
Re: What HDL to start with
« Reply #112 on: April 10, 2020, 02:47:36 pm »
I see the idea. I'll have to get ahold of a draft of VHDL-2019 if it's available anywhere.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9931
  • Country: us
Re: What HDL to start with
« Reply #113 on: April 10, 2020, 04:48:27 pm »
As near as I can tell, Xilinx Vivado only supports up through VHDL 2008 and maybe not all of that.  The User Guide shows what special features are defined but around page 214 (of the document) it talks about how to set up VHDL 2008.  I found another comment on the Interwebs that says VHDL 2008 is now enabled by default.

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug901-vivado-synthesis.pdf

I wouldn't expect to see the 2019 version any time soon - at least in Vivado.  Maybe a 3rd party vendor will incorporate it but I have never convinced myself that outsiders can synthesize (actually, place and route) better than the factory.  It is also likely that I'm completely wrong - again!

ETA:  In looking around the IDE, it doesn't seem possible to select VHDL 2008 when a file is created but its properties can be changed by right clicking on the file name and selecting Set File Type from the fly-out menu then selecting VHDL 2008 from the drop-down box.

I don't use any of the advanced features (yet) so I can get by with the default VHDL setting - whatever it is...
« Last Edit: April 10, 2020, 05:02:50 pm by rstofer »
 

Online asmi

  • Super Contributor
  • ***
  • Posts: 2794
  • Country: ca
Re: What HDL to start with
« Reply #114 on: April 11, 2020, 02:29:08 am »
Xilinx is improving SystemVerilog support with almost every release of Vivado. I guess the reason is they constantly improve AXI VIP (which is 100% SystemVerilog and ships with full source code), and so they need better language support.

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9931
  • Country: us
Re: What HDL to start with
« Reply #115 on: April 11, 2020, 02:55:12 pm »
Xilinx is improving SystemVerilog support with almost every release of Vivado. I guess the reason is they constantly improve AXI VIP (which is 100% SystemVerilog and ships with full source code), and so they need better language support.

Which means the language is a moving target.  I wonder how many projects become broken when there is an upgrade. It's interesting that Xilinx turned on full support for VHDL 2008 in Vivado 2018.  Ten years to get to a point where the language was supported and stable.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15246
  • Country: fr
Re: What HDL to start with
« Reply #116 on: April 11, 2020, 03:27:57 pm »
Xilinx is improving SystemVerilog support with almost every release of Vivado. I guess the reason is they constantly improve AXI VIP (which is 100% SystemVerilog and ships with full source code), and so they need better language support.

Which means the language is a moving target.  I wonder how many projects become broken when there is an upgrade.

If they keep *adding* support for some features without removing anything, this shouldn't break projects after an upgrade. It just means you can never use all features of a given standard at any point until there's full support, which is annoying but shouldn't break anything. Fortunately, those standards are evolving in such a way that backward compatibility is most often ensured, so if you had to use only a subset of new features, your code shouldn't break when support for other features is added.

The fact you'd use a subset of a given standard version tied to the tools you're using sucks though, and said subset should be clearly documented on a project level so any new contributor would know what is allowed and what isn't... In practice, I usually shy away from that and only use a given std version if it's fully supported.

 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9931
  • Country: us
Re: What HDL to start with
« Reply #117 on: April 11, 2020, 06:58:24 pm »
OK, project shouldn't break but will they port to another vendor's tools?

I like the idea of staying with a fully supported version so long as other tools also support it. Even though Vivado appears to fully support VHDL 2008, maybe I'll avoid those extra features (whatever they are).



 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: What HDL to start with
« Reply #118 on: April 11, 2020, 07:44:42 pm »
OK, project shouldn't break but will they port to another vendor's tools?

I like the idea of staying with a fully supported version so long as other tools also support it. Even though Vivado appears to fully support VHDL 2008, maybe I'll avoid those extra features (whatever they are).

Porting to other vendors is more than just HDL support. All of the interesting features of modern FPGAs require, at minimum, “IP core” instantiation, or worse, some kind of “Wizard” to generate the block. The vendors know this, of course. You can be clever and try to write an abstraction layer/wrapper around those vendor-specific blocks, but sometimes it’s easier to realize that porting to a different vendor’s parts means a significant re-design, so why bother.
« Last Edit: April 11, 2020, 07:46:59 pm by Bassman59 »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15246
  • Country: fr
Re: What HDL to start with
« Reply #119 on: April 11, 2020, 11:18:05 pm »
OK, project shouldn't break but will they port to another vendor's tools?

Then this is a slightly different problem... choosing the std version which is supported by most tools around.

At this point, VHDL-2002 is a safe bet. Never had a problem with it. VHDL-2008, OTOH, is still problematic.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: What HDL to start with
« Reply #120 on: April 12, 2020, 02:46:50 am »
I think that when a language lasts for 50 years, the designers did something right.

I feel the same way about VHDL.  I like its verbosity, I like the strict type checking and I'm glad I started with VHDL rather than Verilog.

Like all language wars, there won't be a consensus.  So, to each their own!

I agree on all points. VHDL works well for my brain, I don't like the coding style some people use where they declare all the entities and then instantiate them all rather than just instantiating from the work library but whatever.

I've never really understood why some people are so passionate about their language choice, I guess it becomes a religion and part of their own identity for some. I'm not aware of anything you can define in Verilog that you can't define in VHDL or vice versa. There's also nothing stopping anyone from leaning multiple languages, indeed I'd encourage anyone starting out with HDL to try them both and then go with the one they find easiest to work with.
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 21611
  • Country: us
Re: What HDL to start with
« Reply #121 on: April 12, 2020, 02:50:51 am »
Porting to other vendors is more than just HDL support. All of the interesting features of modern FPGAs require, at minimum, “IP core” instantiation, or worse, some kind of “Wizard” to generate the block. The vendors know this, of course. You can be clever and try to write an abstraction layer/wrapper around those vendor-specific blocks, but sometimes it’s easier to realize that porting to a different vendor’s parts means a significant re-design, so why bother.

Most of these features have mostly equivalent features offered by other vendors. A lot of my early learning projects involved porting existing projects from one vendor to another, I got pretty good at it after a while.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 20505
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #122 on: April 12, 2020, 07:48:23 am »
There's also nothing stopping anyone from leaning multiple languages, indeed I'd encourage anyone starting out with HDL to try them both and then go with the one they find easiest to work with.

Precisely, and the same is true for software languages.

Engineers should be able to realise that, to a good approximation, Java=C#, Pascal=Delphi, Lotus123=Word, Verilog=VHDL,  but that Java/C# != Verilog/VHDL etc.

Once you know one example of each class, you will be able to
  • choose the right class - often not achieved!
  • use whichever example of the class is convenient, with only a short learning curve
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 27836
  • Country: nl
    • NCT Developments
Re: What HDL to start with
« Reply #123 on: April 12, 2020, 09:41:22 am »
There's also nothing stopping anyone from leaning multiple languages,
I'd be careful with this advice. It takes a really long time to learn how to use a programming language effectively. It is not only the syntax but also the libraries which come with it (or a set of vendor specific libraries). As I wrote before: I have invested quite a bit of time to learn the more advanced constructs of VHDL which makes me work very effectively with it. If I had to do the same with Systemverilog I'd be learning a different language with the same goal. That isn't very efficient use of time. BTW you can swap the language names and my claim is still true.

@tggzz: Lotus123 is a spreadsheet; not a word processor and VHDL most certainly isn't equal to Verilog. There is too much missing from Verilog as a programming language to make a meaningful comparison to VHDL. VHDL compares to Verilog like C compares to assembler.
« Last Edit: April 12, 2020, 09:45:44 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: What HDL to start with
« Reply #124 on: April 12, 2020, 10:01:47 am »
.
« Last Edit: August 19, 2022, 03:47:39 pm by emece67 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf