VHDL on the Decline for FPGA Design

[Alexei.Polkhanov]

I will say, though, that choosing a language because the "syntax looks kinda like a language I already know" is silly, because Verilog's C-like syntax has enough deviations from C that you'll choke on them. (I don't know enough Ada to know whether anything I do in VHDL is actually like what you'd do in Ada.)

Not entirely silly. I have been programming in many programming languages for living and for fun. With all languages or groups of languages comes certain philosophy and culture. Ada is more about verbosity in syntax, it is more readable but a bit harder to write code in. If your assumption that small differences can be a problem then how so many programmers, including myself, can switch from C to Java to Objective C to C# in one day many times and stay sane?

So if you know C you will start producing good code in Verilog faster. Then there is articles and books that exploit similarity like here:
http://www.embedded.com/design/real-world-applications/4006420/1/The-C-Programmers-Guide-to-Verilog

I think Ada and  VHDL are more academically sound languages that have some Niklaus Wirth's beauty in them. (He got Turing Award for designing Pascal).
VHDL and Ada has lots of exact or similar syntax constructs. I think if Ada was more successful our world would be much nicer place to live in, but it did not happen.

VHDL:

CASE instruction IS
WHEN load_accum =>
accum <= data;
WHEN store_accum =>
data_out <= accum;
WHEN load|store =>
process_IO(addr);
WHEN OTHERS =>
process_error(instruction);
END CASE;

Ada:

CASE X is
   WHEN 1 =>
      Walk_The_Dog;
   WHEN 5 =>
      Launch_Nuke;
   WHEN 8 | 10 =>
      Sell_All_Stock;
   WHEN OTHERS =>
      Self_Destruct;
END CASE;

Difference is only '<=' assignment.

[tggzzz]

I will say, though, that choosing a language because the "syntax looks kinda like a language I already know" is silly, because Verilog's C-like syntax has enough deviations from C that you'll choke on them. (I don't know enough Ada to know whether anything I do in VHDL is actually like what you'd do in Ada.)

I agree.

Syntax is trivial - even pretty dumb editors can help you get that right!
Semantics are far more important, interesting, powerful - and problematic if you "don't think in the language". Old aphorism: you can write Fortran in any language.

[nctnico]

I will say, though, that choosing a language because the "syntax looks kinda like a language I already know" is silly, because Verilog's C-like syntax has enough deviations from C that you'll choke on them. (I don't know enough Ada to know whether anything I do in VHDL is actually like what you'd do in Ada.)

Not entirely silly. I have been programming in many programming languages for living and for fun. With all languages or groups of languages comes certain philosophy and culture. Ada is more about verbosity in syntax, it is more readable but a bit harder to write code in. If your assumption that small differences can be a problem then how so many programmers, including myself, can switch from C to Java to Objective C to C# in one day many times and stay sane?

In my experience mastering a language is more than being able to read & produce the syntax. Being able to use a language efficiently requires learning the associated libraries and understanding the underlying philosphy. Definitely not something you'll achieve in one day!

This also applies for making a HDL choice based on the employer or customer. If you know VHDL you are not going to apply for Verilog jobs / projects and vice versa.

[hamster_nz]

In my experience mastering a language is more than being able to read & produce the syntax. Being able to use a language efficiently requires learning the associated libraries and understanding the underlying philosphy. Definitely not something you'll achieve in one day!

This also applies for making a HDL choice based on the employer or customer. If you know VHDL you are not going to apply for Verilog jobs / projects and vice versa.

I don't know if that holds all that true for HDLs - for example most text books come in VHDL and Verilog editions, and cover exactly the same concepts, just with different code examples - for example "Introduction to Digital Design" by Richard E. Haskell & Darrin M. Hanna, or "FPGA Prototyping by [VHDL or Verilog] Examples" by Pong P Chu.

I don't see that in any programming books that are in "language X or language Y" editions.

[asgard20032]

Algorithm in C (Sedgewick)
Algorithm in Java (Sedgewick)
Algorithm in C++ (Sedgewick)

--------------------------------------

Programming C# Step by Step some random year (Microsoft press)
Programming F# Step by Step some random year (Microsoft press)
Programming Visual basic# Step by Step some random year (Microsoft press)

[BloodyCactus]

Algorithm in C (Sedgewick)
Algorithm in Java (Sedgewick)
Algorithm in C++ (Sedgewick)

also stuff like

Modern Compiler Implementation in C - Andrew Appel
Modern Compiler Implementation in Java - Andrew Appel
Modern Compiler Implementation in ML - Andrew Appel

[nctnico]

In my experience mastering a language is more than being able to read & produce the syntax. Being able to use a language efficiently requires learning the associated libraries and understanding the underlying philosphy. Definitely not something you'll achieve in one day!

This also applies for making a HDL choice based on the employer or customer. If you know VHDL you are not going to apply for Verilog jobs / projects and vice versa.

I don't know if that holds all that true for HDLs - for example most text books come in VHDL and Verilog editions, and cover exactly the same concepts, just with different code examples - for example "Introduction to Digital Design" by Richard E. Haskell & Darrin M. Hanna, or "FPGA Prototyping by [VHDL or Verilog] Examples" by Pong P Chu.

I don't see that in any programming books that are in "language X or language Y" editions.

I wouldn't trust a book which has examples in different languages side by side. It won't show you the most efficient way of doing things in either language. For example if you want to sort data in C you have to do a lot of work using pointers and implement a clever algorithm yourself. In C++ you just use a STL container for the data and call the sort method.

[hamster_nz]

I wouldn't trust a book which has examples in different languages side by side. It won't show you the most efficient way of doing things in either language. For example if you want to sort data in C you have to do a lot of work using pointers and implement a clever algorithm yourself. In C++ you just use a STL container for the data and call the sort method.

I don't trust the books, but here are a couple more exhibits for you:

Exhibit #1- A 100 MHz SDRAM controller I wrote in VHDL. http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller#Version_0.5_-_Enhanced_debugging

Exhibit #2 - The same SDRAM controller ported to Verilog, for a local university project that needed Verilog memory controller with a GNU header on it. http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller#Verilog_version_0.1  - It was first Verilog project and it took me a few hours to port over a couple of nights.

Exhibit #3 - From the the qsort() man page (qsort is part of the standard C library):

Code: [Select]

     #include <stdlib.h>
     #include <stdio.h>

     static int
     intcompare(const void *p1, const void *p2)
     {
         int i = *((int *)p1);
         int j = *((int *)p2);

         if (i > j)
             return (1);
         if (i < j)
             return (-1);
         return (0);
     }

     int
     main()
     {
         int i;
         int a[10] = { 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
         size_t nelems = sizeof (a) / sizeof (int);

         qsort((void *)a, nelems, sizeof (int), intcompare);

         for (i = 0; i < nelems; i++) {
             (void) printf("%d ", a[i]);
         }

         (void) printf("\n");
         return (0);
     }


[Alexei.Polkhanov]

This also applies for making a HDL choice based on the employer or customer. If you know VHDL you are not going to apply for Verilog jobs / projects and vice versa.

I have not seen single job ad for many years that does not require 'expert' knowledge of BOTH. Perhaps it is North American thing.

[Bassman59]

This also applies for making a HDL choice based on the employer or customer. If you know VHDL you are not going to apply for Verilog jobs / projects and vice versa.

I have not seen single job ad for many years that does not require 'expert' knowledge of BOTH. Perhaps it is North American thing.

That must be a big-company HR thing, because the last couple of times I've looked for a new job, the small companies all specified one of the languages, not both. I don't see how a small company can manage using both languages (or worse, adding SystemVerilog to the mix, or even more worse, adding some kind of C-to-gates shit) for design.

What happens in any event is that you get into the interview and you ask, "what language do you all use?" and you'll get one answer.

[kfnight]

Mentor has the results in from their latest survey / study, with around 1800 participants. VHDL is still on the decline, and even vanilla Verilog. But look at SystemC / C / C++; more people are, or would eventually like, trying out (semi) high-level synthesis.

[legacy]

anyway, my attempt to merge up C with vhdl for testbench purposes has got some new progress 

I am using gcc + gHDL because I am experimenting this solution in order to test a new algorithm which converges ( I hope) to the exponentiation of complex numbers

I has been studied on Mathematica, then ported to C, then moved from floatingpoint domain to fixedpoint domain (1), tuned (you have some significance loss issue), precision fixed, and finally moved from C to vhdl

but the testbench is still written in C, and I am interfacing it with the gHDL engine in order to test every blocks in the algorithm (e.g. the range-reduction block, the sign estimator block, the ReIm-network, etc etc)

this strategy is better than the attempt of porting those tests to vhdl: also with C-gHDL I can have "pipes" which interact with the linux underground, therefore I can also interface inputs and outputs with Octave/Matlab/Mathematica, which also means I have a better screenshots to show 



(1) C++ offers the possibility to "overload" operators (+,-,*,/,%,=,>,<,>=,<=,!,...), so you can have a more comfortable fixedpoint engine which looks builtin the language and as good as the floatingpoint which comes really builtin and offered by the C language

[aandrew]

I use Verilog - I come from a C background, and was given the opportunity to learn either Verilog or VHDL. I looked at VHDL and it just looks a hell of a lot more confusing - the code is split up a lot more into different blocks. Where as, Verilog allows the code to be cleaner and more compact.

Interesting. I too come from a C background and I chose VHDL over Verilog specifically because it was NOT like C. I would get caught up writing C-like structures and of course that doesn't work overly well.

There's also something I really quite like about strong (to put it mildly) typing in VHDL which really forces me to think about what I'm doing. I would never, ever want that in my C code though (integer promotion FTW).

I also rather like the simplicity of VHDL; Verilog almost goads you into writing bad HDL because it allows you "think" in code. With VHDL I find I tend to "think" in HDL and writing good HDL in VHDL comes more naturally to me. I really do agree with Jan Decaluwe's assertion that VHDL's crown jewel is the delta cycle; it's such a simple concept. The fact that this doesn't intrinsically exist in Verilog boggles my mind. I know that everyone writes their Verilog with the same idea in mind, but it feels like I'm fighting the language.

In the end, excellent code is written in all of these languages, and people are continually trying to come up with new HDLs to make it even better.

[Sal Ammoniac]

When I started working with FPGAs recently I learned both VHDL and SystemVerilog. My reasoning was that I should know enough about both to make a good decision as to which one to use long term, and also to be able to read examples in whatever language I didn't use. I alternated languages for each new project and ultimately implemented all projects in both languages.

After several months of using this dual language approach, I settled on SystemVerilog and use it almost exclusively now. I find the verbose syntax of VHDL too tedious and dislike having to cast everything to make it fit the data type I'm trying to use. Although I'm a long-time embedded C programmer (35 years), I've had no problems thinking in HDL and don't tend to write HDL code like I'd write C. I always keep in mind that I'm describing hardware rather than programming a CPU, so I don't find Verilog to be a disadvantage in this regard.

SystemVerilog has some nice improvements over vanilla Verilog, so I recommend that beginners use it rather than Verilog if their development tools support it. I use Vivado and it has good support for SystemVerilog.

[nctnico]

If VHDL is longwinded and you need to cast everything then you are not planning your projects right and are thinking too in hardware instead of describing a problem.

[Someone]

If VHDL is longwinded and you need to cast everything then you are not planning your projects right and are thinking too in hardware instead of describing a problem.

Doing arithmetic operations and sending results to-from ram is a common example of needless casting since you can only address with an integer type, or the different ternary functions for different contexts when in verilog they are uniform. You either like strongly typed languages or you don't, neither is superior.

[nctnico]

If you define the ram as an array of the type you are using for the arithmatics you don't need to cast anything for source/result. A lot of this comes down to planning the types during the design stage. In my experience you should avoid std_logic_vector for anything which is a number (whether it is a value or an index). You'll see that you won't be using std_logic_vector at all except for signals which really need to be bit field.

[AndyC_772]

I think the point here is that the address and data inputs to a hard RAM block are STD_LOGIC_VECTORs, like it or not.

Quartus will accept something along the lines of:

Code: [Select]

my_memory: dpram PORT MAP (
  address => CONV_STD_LOGIC_VECTOR (a, 8),
  data => CONV_STD_LOGIC_VECTOR (d, 8)
);

... but ModelSim will choke on it, and insist on:

Code: [Select]

a_vec <= CONV_STD_LOGIC_VECTOR (a, 8);
d_vec <= CONV_STD_LOGIC_VECTOR (d, 8);

my_memory: dpram PORT MAP (
  address => a_vec,
  data => d_vec
);

Do you know of a more elegant solution?

[nctnico]

Simple: create an array and let the synthesizer infer memory. That way you can always scale a design up and down without having to care what kind of memory resource is to be used. Ofcourse you have to keep the memory structures supported by the hardware in mind so you aren't creating something which the synthesizer can't deal with.

[Sal Ammoniac]

If VHDL is longwinded and you need to cast everything then you are not planning your projects right and are thinking too in hardware instead of describing a problem.

I'm curious--when you're writing embedded code for an MCU do you use Ada?

[nctnico]

If VHDL is longwinded and you need to cast everything then you are not planning your projects right and are thinking too in hardware instead of describing a problem.

I'm curious--when you're writing embedded code for an MCU do you use Ada?

No but that is mostly due to lack of (embedded) ARM support for Ada.There are many things I'd like the 'language' to do for me in order to reduce the chances of programming errors. Think about bounds checking, not needing pointers all the time, etc. At some point using C gets tedious because you have to do so many things yourself if you want to create robust software.

[chris_leyson]

I honestly don't understand this discussion. The choice of HDL is made by your employer.

Probably a lot of truth in that, ESA did a nice set of VHDL guidelines back in '94 which makes for a good read, not sure if they use Verilog though, but probably a lot of companies stick to one or the other if they have large development teams. I'm self taught in VHDL only because I couldn't get my head around the Verilog syntax, shame really it would be nice to be proficient in both not that I am that proficient at VHDL anymore havn't used it in 10 years.
Nowadays both VHDL and Verilog are taught at university so maybe there is a bias in the education system somewhere that has filtered through into industry but then again it might be that VHDL is too verbose.

[helius]

No but that is mostly due to lack of (embedded) ARM support for Ada.There are many things I'd like the 'language' to do for me in order to reduce the chances of programming errors. Think about bounds checking, not needing pointers all the time, etc. At some point using C gets tedious because you have to do so many things yourself if you want to create robust software.

C++ can do many of those things, with vectors and iterators. It does come with many of its own pitfalls, and library sizes tend to be huge.

[nctnico]

No but that is mostly due to lack of (embedded) ARM support for Ada.There are many things I'd like the 'language' to do for me in order to reduce the chances of programming errors. Think about bounds checking, not needing pointers all the time, etc. At some point using C gets tedious because you have to do so many things yourself if you want to create robust software.

C++ can do many of those things, with vectors and iterators. It does come with many of its own pitfalls, and library sizes tend to be huge.

Using a library for use on a SoC or PC isn't going to be the best idea but the principles can be used to generate similar functions with a smaller footprint. I really need to get into using C++ on ARM controllers!

[Someone]

If VHDL is longwinded and you need to cast everything then you are not planning your projects right and are thinking too in hardware instead of describing a problem.

Doing arithmetic operations and sending results to-from ram is a common example of needless casting since you can only address with an integer type, or the different ternary functions for different contexts when in verilog they are uniform. You either like strongly typed languages or you don't, neither is superior.

If you define the ram as an array of the type you are using for the arithmatics you don't need to cast anything for source/result. A lot of this comes down to planning the types during the design stage. In my experience you should avoid std_logic_vector for anything which is a number (whether it is a value or an index). You'll see that you won't be using std_logic_vector at all except for signals which really need to be bit field.

The address of inferred rams is required to be an integer, so you cant happily sit in a single type domain and work away, and when you do want to compare data and addresses you're forced to do casting/type conversion.

Similarly unsigned and signed types need to go through an intermediate type before being used with each other, its not a bad thing but its a very roundabout way of designing and adds unnecessary complications when you want to move data around. I can be sure that certain steps in a computation are guaranteed to be unsigned due to upstream constraints, but trying to tell the synthesiser that information in VHDL is very obtuse.