Verilog or VHDL?

[Sal Ammoniac]

I'm curious how many people on this forum use Verilog and/or VHDL...

[ataradov]

Verilog, and even that is too verbose for my taste. I can't deal with the amount of typing required for VHDL.

[exmadscientist]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

(And it's not like VHDL is that verbose, anyway, given its domain. It's certainly a lot more pleasant to write than yet another AbstractFactoryConstructorDelegationVisitorSingletonFactory!)

[scatha]

It depends on the existing project codebase - if it's Verilog I use Verilog, VHDL then I use VHDL. Mixed-source projects can be a pain because invariably someone's chosen port names which are reserved keywords in the alternate language.

I've been too mentally scarred by other people's horrible, horrible Verilog to use it in my personal projects - I tend to use VHDL for synthesis and SystemVerilog for verification which gives me the best of both worlds.

[obiwanjacobi]

I am a hobbiest and invested in learning a bit of VHDL. Being a C/C++/C# developer I am amazed at the verbosity of the syntax and cannot yet type a simple 'program' without looking stuff up - probably because I do not use it very often.

As I learned PSoC5 and their(Cypress) Creator software I have looked into Verilog and it looks a lot simpler, but have not invested in learning that. But I probably will when I need to do some advanced custom components...

[mikeselectricstuff]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

That's the  reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.
 

[hamster_nz]

I use VHDL as that was the language used in an old University Text book I got for $5 at a bookshop sale before I purchased my first FPGA board.

[nctnico]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

That's the  reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.

#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.
In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

[hamster_nz]

#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.
In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

Isn't the stuff within generate blocks still parsed, so it has to be 'correct' code? (e.g. signals need to be defined, no hanging nested 'if's... )

[Cerebus]

VHDL was designed by a committee, a military committee. That single sentence ought to be enough to steer any sane person away from it.

I can pretty much guarantee that almost every bit of VHDL that anyone here has ever seen or written begins (excluding possible comments) with the lines:

Code: [Select]

library IEEE;
use IEEE.std_logic_1164.all;
A hint that there's something fundamentally flawed is when what are essentially the fundamental types most commonly used in a programming language require definition for each and every program, and require you to type something to invoke that definition.

When defending VHDL people always say "type safety" as if it's some magic mantra. Type safety is a wonderful thing, and I heartily encourage anybody designing a programming language to adopt it. The thing is type safety doesn't require an abstruse syntax that requires repeated, pointless verbiage¹. A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL. It's like buyer regret when a car buyer defends their car on its great fuel mileage and you can see their disappointment that they didn't get the little red sports car².

Another hint is in that second line of code. It's the ".all". If you're aiming for as much compile time checking as possible it's a bad idea to design a language in a way that encourages users to include every type in a type library including all the types they don't intend to use. You can't check for unintended type usage if you've set yourself up to encourage unintended type definition.

If you're determined to use VHDL my primary recommendation is a touch typing course, you'll need it.

1 The syntax of VHDL is modelled on ADA. As well as being user hostile, the ADA syntax is compiler hostile too. It's one excuse to mangle the formal syntax of a programming language to make it easier for the users, it's another excuse to make it easier for the compiler writer, but mangling it for both is close to a useful working definition of insanity. As they say in the British Army: "There are three ways to do a job. There's the right way, the wrong way and there's the Army way.".

2 The author does have a little red sports car, and has few if any regrets.

[Kilrah]

A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL.

It's different, you usually don't program in C because you chose to, it's just that it's where everything is. If you later get to choose your HDL you might want to precisely try something else that hypotherically could help you avoid the mistakes you know all too well about.

I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

[hamster_nz]

I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

This works just fine:

Code: [Select]

architecture Behavioral of tb_debug_test is
    component debug_test is
    Port ( clk        : in  STD_LOGIC;
           serial_out : out STD_LOGIC;
           probes     : in  STD_LOGIC_VECTOR (8 downto 0));
    end component;
   ...
begin
  ...
i_debug_test : debug_test port map (clk, serial_out, counter);
  ...

Let us know how well it works out for you...

[nctnico]

A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL.

It's different, you usually don't program in C because you chose to, it's just that it's where everything is. If you later get to choose your HDL you might want to precisely try something else that hypotherically could help you avoid the mistakes you know all too well about.

BTW Nowadays a good C/C++ compiler throws an error if you use the wrong type and don't explicitly cast it.

I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

You can use packages (only one component instantiation) and records to reduce the amount of text significantly. If you have a bunch of related variables in C you typically put them in a struct and pass the struct to a function instead of each variable seperately.

[Kilrah]

Let us know how well it works out for you...

Well you still need internal signals, don't you?

What I mean is that the following:

Code: [Select]


entity design_1 is
  port (
    btn : in STD_LOGIC;
    clk : in STD_LOGIC;
    led : out STD_LOGIC;
    sw : in STD_LOGIC_VECTOR ( 3 downto 0 )
  );
end design_1;

architecture STRUCTURE of design_1 is
  component design_1_clk_wiz_0_0 is
  port (
    clk_in1 : in STD_LOGIC;
    clk_out1 : out STD_LOGIC
  );
  end component design_1_clk_wiz_0_0;
  component design_1_pwm_0_0 is
  port (
    clk_i : in STD_LOGIC;
    reset_i : in STD_LOGIC;
    led_o : out STD_LOGIC;
    val_i : in STD_LOGIC_VECTOR ( 3 downto 0 )
  );
  end component design_1_pwm_0_0;
  signal btn_1 : STD_LOGIC;
  signal clk_1 : STD_LOGIC;
  signal clk_wiz_0_clk_out1 : STD_LOGIC;
  signal pwm_0_led_o : STD_LOGIC;
  signal sw_1 : STD_LOGIC_VECTOR ( 3 downto 0 );
begin
  btn_1 <= btn;
  clk_1 <= clk;
  led <= pwm_0_led_o;
  sw_1(3 downto 0) <= sw(3 downto 0);
clk_wiz_0: component design_1_clk_wiz_0_0
     port map (
      clk_in1 => clk_1,
      clk_out1 => clk_wiz_0_clk_out1
    );
pwm_0: component design_1_pwm_0_0
     port map (
      clk_i => clk_wiz_0_clk_out1,
      led_o => pwm_0_led_o,
      reset_i => btn_1,
      val_i(3 downto 0) => sw_1(3 downto 0)
    );
end STRUCTURE;

Should be possible to express with:

Code: [Select]

entity design_1 is
  port (
    btn : in STD_LOGIC;
    clk : in STD_LOGIC;
    led : out STD_LOGIC;
    sw : in STD_LOGIC_VECTOR ( 3 downto 0 )
  );
end design_1;

architecture STRUCTURE of design_1 is
  signal clk_wiz_0_clk_out1 : STD_LOGIC;
begin
clk_wiz_0: component design_1_clk_wiz_0_0
     port map (
      clk_in1 => clk,
      clk_out1 => clk_wiz_0_clk_out1
    );
pwm_0: component design_1_pwm_0_0
     port map (
      clk_i => clk_wiz_0_clk_out1,
      led_o => led,
      reset_i => btn,
      val_i(3 downto 0) => sw(3 downto 0)
    );
end STRUCTURE;

I.e.
- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...
- Skip the local signals that have no other purpose than connecting a port of the entity straight to a port of a component, connect those directly
- Local signals that are used to connect ports between components are fine, they're required due the possibility of having multiple instances of the same component, no issue there.

You already save half the code lines, and it seems you don't lose anything. You need a little more back and forth between files to check component declarations when doing the mapping, but I'd take that any day over having to copy them across and maintain that copy, every language requires that kind of thing anyway.

Disclaimer: I'm pretty much a beginner in VHDL and I'm probably missing something including the possibility that my proposed version could be OK  , and I've never tried verilog so maybe that does just this - if so I'd happily have a look at it, I'm here to learn!

Note: obviously modern tools e.g. Vivado are able to hide that away from you by autogenerating the top module from the much easier to specify graphical block diagram, but still.

[mikeselectricstuff]

There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.

That's the  reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.

#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.
In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

You can do some things using constants but it's often more fiddly and there are some things you just can't easily do. I'm specifically thinking build variants where you may want to selectively include/exclude whole blocks, or have completely different functionality, which #ifdef could do much more easily.
#ifdef would also be an easy way to work round the lack of block comments for temporarily disabling sections for debugging.

[Kilrah]

OK, just ran a quick test, and interestingly

- Skip the local signals that have no other purpose than connecting a port of the entity straight to a port of a component, connect those directly

This seems perfectly fine 

- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...

Big nope for that one though

That's already something though! I'm all for fewer indirections, having to create and assign useless signals was nothing other than an opportunity for mistakes IMO.

And that was another learning opportunity to port a design from a board to another , and integrate some autogenerated code from a Vivado block design into a pure code project. I'm starting to get a hang of the tools and their "behind the scenes" workings if anything 

[asgard20032]

I tried both, and there is mostly one thing I would like to be ported to Verilog : type. Being able to create a type, like an enum, for state machine, is a clean approach. Just implement something like enum/type for Verilog just for the sake of state machine.

[parasole]

I learned FPGA programming myself as hobbyist, initially started with Verilog, however it turn out VHDL to be much easier to learn and understand... By now I am doing every thing in VHDL and use Verilog only as readily available functions, although may adjust them to my need if required...

[Someone]

- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...

Big nope for that one though

Time to learn the entity declaration:
http://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations.html

[dmills]

I come from the background of having an expert knowledge of C, so I quite deliberately set out to learn VHDL, Verilog is just sufficiently C like that I find myself in a 'software' mindset and HDL written as if it was sequentially executing software is horrible when it works at all.

The verbosity is a price worth paying for making things explicit IMHO, and do NOT underestimate that type safety thing, annoying? Sure, but less so then trying to figure out why the thing has guessed wrong about a signed/unsigned math operation.

Regards, Dan.

[rstofer]

VHDL was designed by a committee, a military committee. That single sentence ought to be enough to steer any sane person away from it.

I can pretty much guarantee that almost every bit of VHDL that anyone here has ever seen or written begins (excluding possible comments) with the lines:

Code: [Select]

library IEEE;
use IEEE.std_logic_1164.all;
A hint that there's something fundamentally flawed is when what are essentially the fundamental types most commonly used in a programming language require definition for each and every program, and require you to type something to invoke that definition.

#include <stdio.h>
#include <stdint.h>

[legacy]

vhdl under CoNix with ghdl + gtkwave (sometimes ModelSim) and ISE-v14.1
edit:
oh, I am also tempted by VHDL-AMS(1), it's a derivative of  VHDL
(IEEE standard 1076-1993), and it includes analog and mixed-signal extensions
but ... it's not supported by ghdl 


(1) you can, in the theory, describe a PLL, or things that require pspice
so, it sounds interesting, in the theory, where in the practice it's useless
mainly because you can't find an useful tool

[Kilrah]

Time to learn the entity declaration:
http://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations.html

Interesting, thanks for the link!

Seems "Four-and-a-half" matches what I'd like, unfortunately it doesn't seem to work in Vivado (seems to be equal to "One", only works if the declaration is present).
"Four" does the job, but a caveat is that it won't work if the component is written in Verilog, have to go back to "One" again for those.
Haven't tried "Two" yet, "Three" just seems too messy to use.

[ataradov]

Just implement something like enum/type for Verilog just for the sake of state machine.

Then you need to look at SystemVerilog. It implements many new features like this, while keeping syntax clean and simple.

[Sal Ammoniac]

Interesting results so far. Most of the responders have been from Europe or Oceania, so the skew towards VHDL isn't surprising as those are two VHDL strongholds. It'll be interesting to see if the results change as North Americans wake up and cast their votes. Out where I am (Silicon Valley), HDL usage tends to heavily favor Verilog.

I cast my vote for "both" because I just got started with FPGAs a few weeks ago and haven't decided whether I like Verilog or VHDL best. Each has its strong points and annoyances, so I'm alternating between them until I settle on one or the other.

I find VHDL too verbose for my taste, and its extreme type safety just too much. I'm primarily an embedded C type, so perhaps if I worked in Ada I wouldn't be so turned off by this.

Verilog is more like what I'm used to in a language, but it also has its issues. I'm constantly forgetting the differences between blocking and non-blocking assignments and constantly forgetting to use "assign" before a con-current statement. Since Verilog is so C-like already, I wish that they'd made it a little more succinct by using {}s rather than begin/end.