What HDL to start with

[JustClaire]

Hello!

I am a complete newbie to FPGAs and currently deciding which HDL to start with. So far i am deciding between the more popular VHDL or Verilog and something like MyHDL or SpinalHDL.
Which one would you suggest based on the software & hardware support(IDEs, simulators, compilers, etc.) and ease of learning?

Another major deciding factor for me is the cost of the software, i'd prefer free software as i am not ready to pay 500$ for a licensed copy of a development package  .

Thank you

[OwO]

Choice of language isn't as important as understanding the concepts of digital logic design. I would personally start with a traditional language (VHDL or SystemVerilog), and try the new stuff later when you are familiar with hardware design. The most important thing to remember is that designing FPGA logic is *not* writing software, it's designing a circuit. Your code should reflect that; it's basically just a fancy netlist.

[JustClaire]

Choice of language isn't as important as understanding the concepts of digital logic design. I would personally start with a traditional language (VHDL or SystemVerilog), and try the new stuff later when you are familiar with hardware design. The most important thing to remember is that designing FPGA logic is *not* writing software, it's designing a circuit. Your code should reflect that; it's basically just a fancy netlist.

What software would you suggest to start with SystemVerilog?

[mark03]

What software would you suggest to start with SystemVerilog?

Will you be learning "hands on" with an FPGA dev board?  If so, the free version of Vivado (Xilinx) supports SystemVerilog, and I think the free version of Quartus (Altera/Intel) does too.  If you want to start in pure simulation without an actual FPGA, those same tools have simulators built in.  There is also the free Verilator which supports SystemVerilog.

The trick with the Verilog "family" in particular is that it has been a moving target for 20+ years and, generally, the free tutorials and examples you find on the web will not be using SystemVerilog best practices.  I can recommend Stuart Sutherland's book "RTL modeling with SystemVerilog for simulation and synthesis".

Note that SystemVerilog is actually a huge language spec, most of which is irrelevant for synthesis and FPGA design.  But the improvements to old-fashioned Verilog in the "synthesizable subset" are still significant.

[JustClaire]

What software would you suggest to start with SystemVerilog?

Will you be learning "hands on" with an FPGA dev board?  If so, the free version of Vivado (Xilinx) supports SystemVerilog, and I think the free version of Quartus (Altera/Intel) does too.  If you want to start in pure simulation without an actual FPGA, those same tools have simulators built in.  There is also the free Verilator which supports SystemVerilog.

I will most likely start only with simulation untill i get a dev board.

  I can recommend Stuart Sutherland's book "RTL modeling with SystemVerilog for simulation and synthesis".

Thank you, i will check it out!

[nctnico]

Choice of language isn't as important as understanding the concepts of digital logic design. I would personally start with a traditional language (VHDL or SystemVerilog), and try the new stuff later when you are familiar with hardware design. The most important thing to remember is that designing FPGA logic is *not* writing software, it's designing a circuit. Your code should reflect that; it's basically just a fancy netlist.

NO!!! If you go this route you'll be writing a lot of very bad and poorly maintainable code and achieve very little. I've seen this over and over. The trick is to understand how your code is translated into FPGA primitives. But other than that the most time efficient way is to treat writing FPGA exactly like you are writing software. And actually VHDL is more suitable for that compared to Verilog. The only exception are parts that need to meet critical timing but in most cases 99% of the FPGA logic isn't very time critical. It is kind of the trade-off between using C (treat as software problem) and assembly (think in hardware primitives). Modern synthesis tools are very capable of translating HDL into FPGA primitives. As the author you don't need to care.

Just a simple example: instantiating blockram (on a Xilinx) versus declaring an array. An array is declared using one line of code, has an x number of bits and y depth. If the memory needs to be bigger (or smaller) then you only need to change y. The synthesizer/placer/router will figure out what kind of memory fits best so the code is very scalable. The memory depth can even be a parameter so if the module is universal (like a FIFO) some instantiations will use small memory blocks while other will use blockrams.

Another good thing of VHDL are records (structs in C). Use these to combine related signals and pass these to modules as one variable. It saves writing a ton of code. Last but not least a common mistake in VHDL is to use a vector for signals which are a number. Use the signed and unsigned types; these are easy to use as indexes to arrays which again saves writing a lot of code. In one project I inherited the authors went as far as writing special Python scripts to generate VHDL code. Needless to say this is a very cumbersome way to achieve what they wanted AND they could have achieved the same if they used VHDL directly. Now the project is a convoluted mess with Python and VHDL. The bottom line is: try to make the HDL work for you. There will be a learning curve to go beyond average but there are great rewards.

[asmi]

NO!!! If you go this route you'll be writing a lot of very bad and poorly maintainable code and achieve very little. I've seen this over and over. The trick is to understand how your code is translated into FPGA primitives. But other than that the most time efficient way is to treat writing FPGA exactly like you are writing software.

This approach only works if your goal is to design something that runs at 1 MHz. It will fail badly if you need your design to run at any decent frequency.

And actually VHDL is more suitable for that compared to Verilog.

And how do you know that it's more suitable if you don't know SystemVerilog at all?

Another good thing of VHDL are records (structs in C). Use these to combine related signals and pass these to modules as one variable. It saves writing a ton of code. Last but not least a common mistake in VHDL is to use a vector for signals which are a number. Use the signed and unsigned types; these are easy to use as indexes to arrays which again saves writing a lot of code. In one project I inherited the authors went as far as writing special Python scripts to generate VHDL code. Needless to say this is a very cumbersome way to achieve what they wanted AND they could have achieved the same if they used VHDL directly. Now the project is a convoluted mess with Python and VHDL. The bottom line is: try to make the HDL work for you. There will be a learning curve to go beyond average but there are great rewards.

VHDL is going the way of dodo, just like Basic and Pascal are. No reason to bother with it.

[mark03]

There's no sense in starting another language war.  Pick from Verilog, SystemVerilog or VHDL - all will get the job done and they are more similar than different.

This may be true in a narrow sense, but I think it would be hard coming up with reasons to pick Verilog over SystemVerilog in the year 2020, unless you are stuck working with older tools like Xilinx ISE.  Also, for the record (VHDL pun intended), some of the comments on Verilog vs VHDL are outdated.  For example, SystemVerilog has structures and interfaces.

More generally, there is a sort of deep-seated conservatism within the HDL world, which makes it slow to adopt improvements in languages, tools, and techniques.  I saw this in previous workplaces, where just getting the FPGA guys to use mainstream source-control tools (git) was an uphill battle.  You can also see it in Xilinx's choice of tcl (!), of all things, for the scripting language underlying their shiny new toolset.  I think it just goes with the territory.  Software people like to move fast and break things.  Hardware people are deeply suspicious of change, because any breakage has a much higher cost in hardware.

[nctnico]

NO!!! If you go this route you'll be writing a lot of very bad and poorly maintainable code and achieve very little. I've seen this over and over. The trick is to understand how your code is translated into FPGA primitives. But other than that the most time efficient way is to treat writing FPGA exactly like you are writing software.

This approach only works if your goal is to design something that runs at 1 MHz. It will fail badly if you need your design to run at any decent frequency.

That is your opinion but I have been following the exact principle for almost 2 decades very succesfully in commercial projects running at the FPGA's intermediate frequency (the frequency where timing is not likely to become cricitical; IOW usually 99% of the logic running at several tens of MHz). Maybe you should just give it a try; you'll pre surprised how much you can achieve with very little code. Usually I need at least 5 times less lines of code to achieve the same compared to the average VHDL out there. And my solution is scalable on top of it without getting into trouble with timing. However I did invest the time to learn how VHDL language constructs are translated to FPGA primitives. You are making the C versus assembly argument all over again (and we already know the outcome of that).

And actually VHDL is more suitable for that compared to Verilog.

And how do you know that it's more suitable if you don't know SystemVerilog at all?

Looked into it but SystemVerilog  is just the same old Verilog with some stuff from VHDL bolted onto it (note that I wrote Verilog BTW). There is still a lot of opportunity to shoot yourself in the foot. Not saying VHDL is perfect and irreplaceble but the strong types in VHDL and other language constructs are definitely a plus to catch errors which would be hard to find otherwise.

[coldfiremc]

Every time that system verilog gets an upgrade, it's a feature coming from VHDL. VHDL inference is a little more deterministic than verilog. Note that if you don't like "if it not compiles, is because is a nonsense" languages, VHDL is not your language. This appears to begineers as a "disadvantage", but there aren't debuggers in the same sense of software for HDL's, so if it compiles, you can't check check in the same way that the code you write is correct. Note that HDL debuggers are mostly paid.
More code isn't always more work. There's lots of code snippets and templates for vhdl, so there's less need for manual writing.

[asmi]

That is your opinion but I have been following the exact principle for almost 2 decades very succesfully in commercial projects running at the FPGA's intermediate frequency (the frequency where timing is not likely to become cricitical; IOW usually 99% of the logic running at several tens of MHz).

Lol about 80% of my HDL IS timing-critical and is running at 150 MHz and above.

Maybe you should just give it a try; you'll pre surprised how much you can achieve with very little code. Usually I need at least 5 times less lines of code to achieve the same compared to the average VHDL out there. And my solution is scalable on top of it without getting into trouble with timing. However I did invest the time to learn how VHDL language constructs are translated to FPGA primitives. You are making the C versus assembly argument all over again (and we already know the outcome of that).

The problem is the moment you get a timing error you're screwed because in most cases you won't be able to even tell what exactly caused it. Try to P&R any of your "software" code by setting a system clock to 150 MHz and see what happens.

Looked into it but SystemVerilog  is just the same old Verilog with some stuff from VHDL bolted onto it (note that I wrote Verilog BTW). There is still a lot of opportunity to shoot yourself in the foot. Not saying VHDL is perfect and irreplaceble but the strong types in VHDL and other language constructs are definitely a plus to catch errors which would be hard to find otherwise.

This is what I meant - you obviously have no idea what are you talking about, yet you're going on here like you do. You can make SystemVerilog almost just as type-safe as VHDL if you so desire.
As for "stuff from VHDL bolted on" - care to show interfaces in VDHL, or inheritance, or modports? This is the stuff I use all the time. Infact, I would take SV just for interfaces as they make things SO much easier and cleaner. While you're getting buried under tons of stupid boilerplate code (port map? seriously? another copy-paste for absolutely zero reason).

[asmi]

Every time that system verilog gets an upgrade, it's a feature coming from VHDL. VHDL inference is a little more deterministic than verilog. Note that if you don't like "if it not compiles, is because is a nonsense" languages, VHDL is not your language. This appears to begineers as a "disadvantage", but there aren't debuggers in the same sense of software for HDL's, so if it compiles, you can't check check in the same way that the code you write is correct. Note that HDL debuggers are mostly paid.

Why is that VDHL users are so ignorant and arrogant?

More code isn't always more work. There's lots of code snippets and templates for vhdl, so there's less need for manual writing.

Lol. More USELESS boilerplate code is BAD because actual useful logic gets buried under that stupid boilerplate. There is a reason dynamically-typed languages are so popular nowadays, while super-strongly typed Pascal is as good as dead.

[coldfiremc]

Lol. More USELESS boilerplate code is BAD because actual useful logic gets buried under that stupid boilerplate. There is a reason dynamically-typed languages are so popular nowadays, while super-strongly typed Pascal is as good as dead.

Perhaps if you code to gate level, more text is a terrible thing, totally agree, also Verilog and SV tend to be lot better declaring logic explicitly. However if someone wants more behavioral-like code, languages that compel the programmer to write in certain "fixed" ways, make compilers/synthesizers behave more predictibly. Some V's are almost impossible to understand when some other people write code that tries to infer sequential stuff (Or yourself 3 months later). Fortunately SystemVerilog has some ways to avoid this mimicking some vhdl styles and avoids things like Port Map (Despite that I don't think is bad if you use helpers to code it).
Also types must be evaluated sooner or later, and during simulation isn't a good time to do it. Spents time and generates LOTS of useless data until type is evaluated.

[nctnico]

That is your opinion but I have been following the exact principle for almost 2 decades very succesfully in commercial projects running at the FPGA's intermediate frequency (the frequency where timing is not likely to become cricitical; IOW usually 99% of the logic running at several tens of MHz).

Lol about 80% of my HDL IS timing-critical and is running at 150 MHz and above.

Your exception doesn't make the rule. And it isn't even certain that hand optimised code is actually much faster compared to letting the synthesizer deal with it. Compare it to the various optimisation levels a C compiler offers. Size versus speed for example. A HDL synthesizer offers similar settings including ignoring the hierarchy of your design and taking the hardware platform into account. The latter offers a scope of optimisation which is (like C) hard to achieve manually. You need to do something really really special in order to make hand-optimised code being cost effective (time/money spend versus cost of more capable hardware). Like any electronic part FPGAs do go obsolete and having code which can be used on a different platform without needing extensive rewrites can save a lot of time/money.

[tggzzz]

My attitude is mixed...

Sometimes I want a specific hardware primitive available in a specific logic family, e.g. when crossing clock domains or i/o structures (especially SERDES). In those cases I "manually" instantiate the specific primitives.

Where designing a datapath, especially involving arithmetic, I'll adopt a programming language approach, giving the toolset as much information as possible about my use of the data in the datapath, e.g. signed/unsigned, width etc.

Where designing the control and sequencing, I'll adopt an FSM style (frequently a "two process" register+async style), making the code as simple and readable as possible.

But non-dogmatic good taste trumps all of those

[OwO]

Actually no, the code I write in dataflow form is nearly always more concise and easy to read than the same thing implemented with processes. I did a survey of my VHDL code a while ago and the majority of modules are less than 200 lines total, with <100 lines in the body.
For example, this is the universal, one-size-fits-all FIFO module I use in all designs:
https://github.com/gabriel-tenma-white/axi-util/blob/master/dcfifo2.vhd

The body is only 80 lines of code. Looking at the code I can easily form a picture in my head, which consists of a RAM block, input logic, and output logic. I can see the state variables which are the registers (anything with rising_edge(clk)). I can see the read/write pointer registers, the logic that decides the next pointer value, the clock domain crossing that allows the read side to see the write pointer and vice versa.

I find code reuse happening far more often in my hardware designs than software, which completely contradicts what most people who write behavioral code says:
https://zipcpu.com/blog/2020/01/13/reuse.html

That blog entry even says reusing FIFO code is hard, which completely baffles the mind. As I said, in hardware I have a single FIFO implementation that I use everywhere, and when I need a new feature added (e.g. synchronous clear) I can easily add it to the module without interfering with existing users.

Such is not the case in software; for example in one STM32 based project I had 3 FIFO implementations. One was thread safe (lockless) with multiple writers (producers-consumer queue) but can't handle big blocks of items (e.g. byte streams) efficiently, another was a ring buffer for stream data, and yet another was for zero-copy direct access appends. It's simply impossible to cover all these cases in a single implementation in the software world.

[OwO]

And no, I do not write "low level" code that instantiates primitives. In fact I try to infer everything whenever possible including DSP units and block ram. I have a module called dsp48e1_multAdd that contains logic exactly describing what a dsp48e1 has in a certain mode, and it gets mapped to a dsp48e1 perfectly. If you try to synthesize this on another FPGA vendor it will actually still work but be non-optimal.

Primitive instantiation is generally restricted to the top level module where I have the part-specific and board-specific clocking and IO structures. Everything else is supposed to be modular and self contained, which is natural in hardware, but good luck trying to write self-contained modules in C/C++. (I have tried, by using hooks/callbacks for all outgoing calls, but it has a performance penalty). For example, I'd like to have a completely generic si5351 driver that is not tied to a specific SPI driver or even platform. This is trivial in HDL, but impossible in software without performance penalties. To do that in C++ I used hooks (custom std::function that does not use dynamic allocation) for SPI calls.

[nctnico]

And no, I do not write "low level" code that instantiates primitives. In fact I try to infer everything whenever possible including DSP units and block ram. I have a module called dsp48e1_multAdd that contains logic exactly describing what a dsp48e1 has in a certain mode, and it gets mapped to a dsp48e1 perfectly. If you try to synthesize this on another FPGA vendor it will actually still work but be non-optimal.

But why not simply use a <= b*c + d? The synthesizer will map this onto a DSP block just as fine. And in your fifo example: why not just do it like this (severaly stripped example from my own synchronous FIFO):


type mem_type is array (g_size-1 downto 0) of std_logic_vector (g_data_width-1 downto 0);
signal mem : mem_type;
 
output <= mem(to_integer(rd_ptr)) ;

mem(to_integer(wr_ptr)) <= input

Much easier and the synthesizer can determine which kind of memory is most optimal to use given the size of the FIFO and available resources.


But I agree with you in general: conditional / parametric synthesis is very powerfull to create truly versatile pieces of code. OTOH in C/C++ you'll end up with only one physical (as in memory filled with code) implementation of a function where in HDL each instantiation creates a seperate physical implementation. In C/C++ you might get close using polymorphism though.

[OwO]

But why not simply use a <= b*c + d? The synthesizer will map this onto a DSP block just as fine.

Yes that is what I did a long time ago, and then I realized there are 3 mandatory* registers: before the multiplier (a, b), after the multiplier, and after the adder. That also means the b,c to output delay is different from the d to output delay. I just find it more tidy to enclose all that in a module with the delays documented. Same thing with ram inference; I prefer to keep it in enclosed in one module so that if I happen to switch to a vendor that requires a different style of inference, it can be easily fixed.

* the 3 pipeline registers in a DSP48E1 are required to run at the speeds advertised in the datasheet

[emece67]

.

[asmi]

Like any electronic part FPGAs do go obsolete and having code which can be used on a different platform without needing extensive rewrites can save a lot of time/money.

You're all over the place now. What does hardware obsolescence have to do with writing the code such that it reflects the circuit to be generated?
Like I said - try running your "software" code at 150+ MHz and try to see if you'll even be able to figure out where to start fixing all timing violations, or it would be easier to just scrap the code as unfixable and write it anew.
That said, I do use behavioral constructs when I know what circuit they create (things like add/sub, multiply, madd, shifts), and will know what do if I get a timing violation going through any of these paths. But it's important to always remember what's going on behind the scenes and don't do stupid stuff like chain arithmetic operations without pipeline registers - this is pretty much a guaranteed timing violation due to extremely long combinatorial chain it produces.

I believe making HDLs feel so much like software languages has been a big disservice to this industry.

[rstofer]

OP, I told you this would happen!  It does every time the choice of languages is discussed.

In the end, the chosen HDL just takes a high level description of some piece of hardware and maps it onto LUTs.  The LUTs don't change, there are just so many in each device and they are generally identical across the device but there may be variations.  To argue that one language is 'faster' than another seems more a statement of the quality of the compiler (and the skill of the compiler writer) rather than a credit to a specific language.

The LUTs only work just so fast and if there are long serial strings of logic the maximum speed slows down.  If you use an if-elsif-elsif-elsif-elsif-else type of priority encoder (where you really didn't mean for the logic to create a priority encoder) then, sure, it's going to be slower than if you get it done in 2 levels.  When this happens, and the logic can't be rewritten, the only alternative is to force a pipeline with registers at various stages in the logic.  This is the kind of thing that shows up in the RTL Schematic, you can see long strings of logic.  Xilinx ISE used to report on the number of levels between registers, I haven't looked for it on Vivado but it is implicit in the Timing Report(s).  But this only comes up if your design is too slow.

You aren't going to need to worry about this any time soon.  There is enough to learn without trying for ultimate speed and most anything you write will probably run at 100 MHz on the new Xilinx Artix 7 devices.  Not blisering fast, but impressive.

Pick a language, any language, the choice simply doesn't matter.  Find tutorials that interest you and use the language used by the author.  If you ever do this stuff for a living, you will probably need to be competent in all 3 languages because your employer is going to TELL you what language to use.  It won't be up for negotiation because they will have their standard based on a decision made years before.  So, start with any of the three and plan to learn the other two as time goes along.

The important thing to realize is that your code ultimately gets transliterated into something digestible by a LUT or series of LUTs  Further, there are certain types of logic blocks that show up constantly and the most important is the MUX because any time you are selecting from more than one signal, you will likely infer a MUX.  Well, darn, there aren't any MUXes in the fabric, just LUTs.  The synthesizer takes you expression of a MUX and maps it to LUTs and it doesn't make a bit of difference which language you started with, you will get a MUX inside LUTs.  Registers are important but they are simply clocked signals which use the D-flop inside the CLB (see below).  Combinatorial logic seems pretty important but, again, that just maps to LUTs and, ultimately, there will be Finite State Machines created in either a single process model or a two process model.  Generally, it is your choice unless your employer says otherwise.

So, you use some high level language to describe these high level logic blocks and the compiler maps the logic to LUTs and it doesn't make a bit of difference which language you use because, given equally talented compiler writers, the output that maps to the LUTs will be the same.  You simply can't create hardware features that don't exist.

Some languages have different features or flavors but, in the end, I would expect to be able to implement any logic in any language.  It may take more or less typing but it should come out the same.

Pick a language and get started.

Technically, a LUT is but one part of a CLB (Complex Logic Block) of which there may be several in a Slice.  See page 19 here:
https://www.xilinx.com/support/documentation/user_guides/ug474_7Series_CLB.pdf

Above I used the term LUT rather expansively.  In most cases CLB is more appropriate but when you look at synthesizer reports, they tend to talk about LUTs, not CLBs.

[rstofer]

OP, look at page 7 here:
http://users.ece.utexas.edu/~patt/05f.360N/handouts/360n.appC.pdf

Do you see all the MUXes (plain trapezoids), well, once you know how to create one MUX, you know how to create them all.
There is one adder for the Program Counter logic and an Arithmetic Logic Unit to perform the arithmetic/logical operations.
The Register File is just an array of unsigned standard logic vectors, the SEXT are just combinatorial statuemtns to sign extend a value in the Instruction Register.

All of this is just the datapath for a rather small RISC type processor.  But look at the MUXes, they're all over the place!

[asmi]

Yes that is what I did a long time ago, and then I realized there are 3 mandatory* registers: before the multiplier (a, b), after the multiplier, and after the adder. That also means the b,c to output delay is different from the d to output delay. I just find it more tidy to enclose all that in a module with the delays documented. Same thing with ram inference; I prefer to keep it in enclosed in one module so that if I happen to switch to a vendor that requires a different style of inference, it can be easily fixed.

* the 3 pipeline registers in a DSP48E1 are required to run at the speeds advertised in the datasheet

You can write it in somewhat behavioral way and still take advantage of DSP pipeline registers because Vivado synthesizer is smart enough to do that for you if you white the code in certain way. I've already showed this example in the past here, so below code is mapped fully onto DSP tile, takes advantage of all pipeline registers and runs at Fmax for DSP tile (550 MHz for speed grade 2 Artix/Spartan-7):

Code: [Select]

module mul_dsp #(
    parameter WIDTH = 17
) (
    input clk,
    input [WIDTH-1:0] arg0,
    input [WIDTH-1:0] arg1,
    output logic [2*WIDTH-1:0] result
);

bit [WIDTH-1:0] a0, a1;

bit [2*WIDTH-1:0] res_pipe[0:1], res;
   
always_ff @(posedge clk) begin
    a0 <= arg0;
    a1 <= arg1;
   
    res_pipe[0] <= a0 * a1;
    res_pipe[1] <= res_pipe[0];
   
    res <= res_pipe[1];
   
    result <= res;
end
endmodule
As you can see, it's easy to read and understand what's going on, and it perfectly maps to the hardware. Note there is an extra pipeline stage at the end to close IO timing (I did actually run it through P&R to confirm it works), in regular "internal" case it is not needed.

[SiliconWizard]

Yup, remember the thread.

Obviously the registering has to be explicit in some way in your code so the synthesis can infer a pipeline - otherwise it won't.