VHDL on the Decline for FPGA Design

[kfnight]

http://blogs.mentor.com/verificationhorizons/blog/2015/06/03/part-6-the-2014-wilson-research-group-functional-verification-study/



What's interesting is that vanilla Verilog is steadily rising.

[ivan747]

How different are they, really? I'm getting taught VHDL in a couple of trimesters. I hope I'm not gonna learn what could become the COBOL of HDLs.

[c4757p]

It doesn't matter what you learn, any passable coder can pick up new languages with relative ease. You're still doing the same things with it.

[miguelvp]

VHDL will give you a stronger foundation.

Interesting paper:

http://www.angelfire.com/in/rajesh52/verilogvhdl.html

In a nutshell, Verilog is easier to learn but VHDL allows more control. Maybe System Verilog reaches the gap but I have not used System Verilog yet.

Myself I did find Verilog easier but I'm determined to use VHDL instead, but for the top level I rather use the schematic form.

As for COBOL, they did make a killing on the Y2K era, and I bet there are still job offers for the few that know Cobol and Report Writer well and they probably get paid in gold bars.

Edit: seems I'm mistaken, I guess I'm glad I'm a C++ programmer instead:
C++:
http://www.indeed.com/salary?q1=C%2B%2B+Developer&l1=
Cobol:
http://www.indeed.com/salary/Cobol-Developer.html

And for those that champion C or Java, well it's not too bad:
http://www.indeed.com/salary?q1=C+Developer&l1=
http://www.indeed.com/salary?q1=Java+Developer&l1=

[John_ITIC]

I've been told by "people in the know" that, apparently, in the U.S., about 50% use Verilog and 50% use VHDL. This seems to be confirmed by the chart. Also, VHDL is mostly used by engineers working with FPGAs for government.

For my own work, I only use Verilog. I see no need to move towards SystemVerilog in my projects. I find VHDL utterly confusing and I would not agree that it is easy to switch from one to another.

[Junkers]

I feel the same way about switching between languages. I prefer VHDL myself, its strong typing style makes code more readable IMO.

[AndyC_772]

How different are they, really? I'm getting taught VHDL in a couple of trimesters. I hope I'm not gonna learn what could become the COBOL of HDLs.

There's a lot more to writing code for FPGAs than just the syntax and semantics of the language.

FPGA design is all about understanding how the device "executes" your code, and how very, very different it is from the sequential, one step at a time execution model that microprocessors and microcontrollers use.

For example, the classic example of how NOT to swap two variables:

a = b;
b = a;

...does actually work, and does produce the desired result, if you write it in VHDL (or Verilog, or whatever) and put it into a clocked process running on an FPGA.

Once you get your head around the execution model, the fact that you may need to express intent using a different syntax won't be a problem.

For what it's worth, I've been using VHDL on and off for the last 15 years or so. The language still works, and my next design will undoubtedly be done with VHDL too. Hopefully by the time it's deemed to be a dinosaur, I'll have long since moved on from actually writing code any more.

[nctnico]

For my own work, I only use Verilog. I see no need to move towards SystemVerilog in my projects. I find VHDL utterly confusing and I would not agree that it is easy to switch from one to another.

I agree. I'm a VHDL user. To me Verilog looks like a netlist from a schematics CAD package and not something I would pick up easely. There is too little structure for me. Besides that VHDL can do much more powerful stuff because it is more a programming language than a hardware description language. Then again many people still describe hardware. Just for fun look for a priority encoder written in VHDL. The majority of the people will write a VHDL if-then-else line for each input combination and only a few will write a 3 line function which can do the job for any number of inputs. Also the VHDL syntax is rather lenghty. If you are just describing hardware you have to do a lot of typing.

AFAIK SystemVerilog is trying to bridge the gap between VHDL and Verilog by combining the best features of VHDL and Verilog but it probably takes another decade to become really mainstream.

[6thimage]

For example, the classic example of how NOT to swap two variables:

a = b;
b = a;

...does actually work, and does produce the desired result, if you write it in VHDL (or Verilog, or whatever) and put it into a clocked process running on an FPGA.

That won't work in Verilog (as they are blocking assignments) - you need to do

a <= b;
b <= a;

for the assignment to happen at the end of the clock cycle.

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.

Additionally, there are several things that you can do in Verilog that have no VHDL equivalent - such as reductions (|r will or all the bits of r together, creating a 1 bit output) and repeated concatenations ({5{r}} is equivalent to {r, r, r, r, r}, this in VHDL would be r & r & r & r & r - which (from a C background) is frankly confusing).

However, I believe that it is harder to create bugs in VHDL than it is in Verilog. As VHDL is more verbose (it can have 3 times as many lines of code as equivalent Verilog), it forces the programmer / designer to write in a certain way that removes the chances of making stupid errors. When you have been using Verilog for a while, you don't make these mistakes very often, and so you can write faster. (I remember reading about a little competition / test that was done to try and compare Verilog and VHDL, by getting people experienced in either one of them to create the same design in a very restricted amount of time - with only the Verilog programmers finishing, however, only half of them worked).

In particular in Verilog, there is the difference between wires and registers, which can confuses newcomers (wires are assigned outside always blocks, registers are assigned in always blocks), there are blocking and non-blocking assignments (where the values are assigned immediately after an =, but at the end of a clock cycle for an <=) and setting a 5 bit register to a 1 bit value (or assigning a 1 bit wire to a 5 bit output of a module) is perfectly valid, and will only give a warning in most synthesisers (with simulators ignoring it entirely).

On the whole, I think VHDL is likely to be declining because more people are used to C like languages. But I think it will always remain strong in certain areas, such as government, military and space (ESA chose VHDL to implement their LEON processor in).

[codeboy2k]

I have used both, and I much prefer VHDL over Verilog.  This might be due to my own ancientness, growing up on strongly typed algorithmic software languages and languages that have modularity and packages much like VHDL at does heart.

Todays kids have grown up on javascript, ruby, python, et.al. and don't understand the need to have strong language types and deterministic behaviours.

Verilog will happily convert between types for you and maybe do the wrong thing, VHDL won't.  If I need a type conversion in VHDL I have to write a function (or use a package that has it already) but at least then I know that I am under control of the type conversion process, not at the whim of the compiler, which may get it wrong and I won't know until deep into the testing phase.

I like the deterministic behaviour of VHDL, over Verilog's non-determinism. If you even just compile a Verilog project in the wrong order you can get different results. VHDL's Entity/Architecture pairs makes this a non-issue, and separate compilation in any order is possible. It's similar to C/C++ header .h and implementation .c files . Verilog's include statement is not the same.

For now, I'm sticking with VHDL, but it is true that it is slowly getting left behind, and newer vendor tools are heavily focused on SystemVerilog (which I have not tried) and SystemC ( total yuck! gag me with a spoon )

PS: here's an interesting point for those of us who say they have used Verilog, but not yet tried SystemVerilog.. apparently they are now the same, there is no more Verilog, and since 2009 there is only SystemVerilog.  The 'old' Verilog is now a subset of SystemVerilog and included in the language. 

The confusing name change... In 2009, the IEEE merged the Verilog 1364-2005 and the SystemVerilog
extensions (1800-2005) into a single document. For reasons the authors have never understood, the IEEE
chose to stop using the original Verilog name, and changed the name of the merged standard to
SystemVerilog. The original 1364 Verilog standard was terminated, and the IEEE ratified the 1800-2009
SystemVerilog-2009 standard [6] as a complete hardware design and verification language. In the IEEE
nomenclature, there is no longer a current Verilog standard. There is only a SystemVerilog standard. Since
2009, you have not been using Verilog...you have been designing with—and synthesizing—
SystemVerilog! (The IEEE has subsequently released a SystemVerilog-2012 standard, with additional
enhancements to the original, now defunct, Verilog language.)

- Stuart Sutherland and Don Mills, "Synthesizing SystemVerilog: Busting the Myth that SystemVerilog is only for Verification"

From that same paper, there is a Verilog to SystemVerilog growth chart, and SystemVerilog seems really rich, so I can understand its popularity among new designers.  I might have to visit the dark side and give it a go once again

[6thimage]

Besides that VHDL can do much more powerful stuff because it is more a programming language than a hardware description language.

Such as?

[6thimage]

Verilog will happily convert between types for you and maybe do the wrong thing, VHDL won't.  If I need a type conversion in VHDL I have to write a function (or use a package that has it already) but at least then I know that I am under control of the type conversion process, not at the whim of the compiler, which may get it wrong and I won't know until deep into the testing phase.

I think that is the biggest drawback of Verilog - it is handy in some places, but it is so easy to do it by accident and it won't be picked up.

I like the deterministic behaviour of VHDL, over Verilog's non-determinism. If you even just compile a Verilog project in the wrong order you can get different results. VHDL's Entity/Architecture pairs makes this a non-issue, and separate compilation in any order is possible. It's similar to C/C++ header .h and implementation .c files . Verilog's include statement is not the same.

With the exceptions of defines, I don't think Verilog should have the include statement - all files in a project should be supplied separately to the synthesiser or simulator, then this is not an issue.

But then again, it seems that VHDL forces a certain way, with Verilog you have to follow a set list of best practices to prevent silly errors.

[T3sl4co1l]

Noting that I haven't used lots of high level blocks and integration, and don't know Verilog,

I was taught VHDL, and I fail to see what the big fuss is.  Perhaps this is because my perspective is different.

When I was told that VHDL is a descriptive language, not a sequential programming language, I understood this.  It seems like almost no one ever comes to understand this, to see how (static, combinatorial) logic might be (literally) "spelled out".

Moreover, synthesizers use a very small subset of VHDL; while a real digital logic circuit is perfectly capable of implementing a "delay(10ns)" or what have you, a synthesizer never will; it must be implemented by clock edges instead (which means dramatically more trouble, as you probably have to mux between phases of a PLL -- assuming you have such equipment available -- a PLL being, at heart, an analog function provided by proprietary interface and synthesis, not even realizable in VHDL on its own).

When I write VHDL, I approach it entirely from the angle of RTL.  What logic am I describing?  It starts with a logic diagram, then the implementation follows, and the synthesizer output is checked for correctness (and device operation, and inevitable debug cycles..).  When I talk VHDL with others, I find they regularly try to represent things as programmatical, which is fundamentally wrong; I always go directly to "what logic are you trying to synthesize?" -- and often get blank looks at an apparently alien approach!

Since synthesizers are restricted to a subset, and I'm only trying to describe RTL, writing VHDL is very easy.  Direct (combinatorial) logic operations can be implemented in an architecture.  Sequential (latch/register) operations can be implemented in a process.  Both can be used together, or much of it can be grouped inside the process (it always bothered me that the available combinatorial "conditional"/mux statements/blocks differ for the two areas).  Or you can implement the freaking latches/flip-flops in 'bare metal' so to speak, but don't be surprised if the synthesizer (despite its vast compilational power) doesn't understand that you meant a regular latch, and you end up getting exactly the chain of gates you wrote, with subsequent poor performance.  (But such is sometimes necessary, e.g. if you need to implement a dual clocked flip-flop.  It's very easy to describe such a component in legitimate VHDL, but again, no synthesizer will make it for you.)

Tim

[nctnico]

When I write VHDL, I approach it entirely from the angle of RTL.  What logic am I describing?  It starts with a logic diagram, then the implementation follows, and the synthesizer output is checked for correctness (and device operation, and inevitable debug cycles..).  When I talk VHDL with others, I find they regularly try to represent things as programmatical, which is fundamentally wrong; I always go directly to "what logic are you trying to synthesize?" -- and often get blank looks at an apparently alien approach!

That is -I'm sorry to say this- because they are right. Going at it from an RTL perspective entirely defeats the purpose of using an HDL. If you describe the function instead of the logic you'll get the job done in much less time and produce code which is much easier to understand, maintain and extend. I often need 3 lines of VHDL where others need 20.

Your method is like using Karnaugh diagrams to reduce logic equations by hand while the software tool which can do that for you in less than 1 second is right in front of you.

[Bassman59]

Funny, I have been seeing articles about VHDL's decline for 20 years now.

I've used both Verilog and VHDL over the course of my career, and the decision as to which to use has always been made by employer. Thatsaid, I greatly prefer VHDL, and that's what we use on the job now.

[Bassman59]

When I write VHDL, I approach it entirely from the angle of RTL.  What logic am I describing?  It starts with a logic diagram, then the implementation follows, and the synthesizer output is checked for correctness (and device operation, and inevitable debug cycles..).  When I talk VHDL with others, I find they regularly try to represent things as programmatical, which is fundamentally wrong; I always go directly to "what logic are you trying to synthesize?" -- and often get blank looks at an apparently alien approach!

That is -I'm sorry to say this- because they are right. Going at it from an RTL perspective entirely defeats the purpose of using an HDL. If you describe the function instead of the logic you'll get the job done in much less time and produce code which is much easier to understand, maintain and extend. I often need 3 lines of VHDL where others need 20.

Your method is like using Karnaugh diagrams to reduce logic equations by hand while the software tool which can do that for you in less than 1 second is right in front of you.

I have to agree with this.  If you're not taking advantage of the ability of the language to infer logic from behavioral descriptions, you might as well be doing schematic based designs. If you're not taking advantage of the language's strong typing, and as such using unsigned or signed or integers instead of std_logic_vector for math operations, you're making your life more difficult than necessary.

VHDL is very powerful, and modern synthesis tools really do take advantage of its features. You don't need to write RTL code to get excellent results.

[John_ITIC]

When I write VHDL, I approach it entirely from the angle of RTL.  What logic am I describing?  It starts with a logic diagram, then the implementation follows, and the synthesizer output is checked for correctness (and device operation, and inevitable debug cycles..).  When I talk VHDL with others, I find they regularly try to represent things as programmatical, which is fundamentally wrong; I always go directly to "what logic are you trying to synthesize?" -- and often get blank looks at an apparently alien approach!

I agree 100%. For my designs, I need to have maximum efficiency in the hardware implementation. There is no room for errors or for implementing inefficient designs. Therefore, I always carefully define my state machines in Excel (current state, outputs, transition criteria, next state), implement exactly as defined and simulate via test benches designed with the very same methodology.

It is sometimes somewhat tedious to work highly structured this way but I have found that the quality of the work is consistently high and there are much less confusing bugs in the end implementation. Also, there is always a full correlation between the blue-print of the design and the actual implementation.

I think that the level of abstraction one works on correlates with the details of the results one requires.

Edit: In my designs (Protocol Analyzers) most of the FPGA logic deals with transferring chunks of data between registers and doing bit and byte manipulations such as byte reordering and descrambling. This is essentially all about manipulating data between registers so RTL is the correct abstraction level for my designs. Other designs deal with higher-level things and don't care about the lower-level implementations so higher-level abstractions and languages such as SystemVerilog might make sense. These hardware description languages are all tools and one should use the tool and abstraction level suitable for the job.

[Marco]

So basically you have a schematic entry tool in your brain which translates to VHDL using the architecture specific model of VHDL->FPGA translation which you also internalized.

I'm sure it's the most efficient way, I see Xilinx doesn't even allow schematic entry any more in Vivado, but somehow it seems an inefficient use of neurons.

[hamster_nz]

From the Article:

It’s not too big of a surprise that VHDL is the predominant language used for FPGA RTL design

Alternative reading of numbers..... the number of design starts is increasing, and newcomers to FPGA game  are choosing to use Verilog or SystemVerilog (for better of for worse ).

Also, how come do the percentages add up to more than 100%  The imaginary purple (a.k.a.  "projected design language adoption trends within the next twelve months") figures add up to about 180% by my eyeball).

How can about 30% of designs be moving to SystemVerilog in one year, where the previous year's growth was 5%? That is like almost 1/3rd of all designs???

Numbers look either wrong, dodgy, out of context, or made for marketing purposes to me...

[John_ITIC]

So basically you have a schematic entry tool in your brain which translates to VHDL using the architecture specific model of VHDL->FPGA translation which you also internalized.

I'm sure it's the most efficient way, I see Xilinx doesn't even allow schematic entry any more in Vivado, but somehow it seems an inefficient use of neurons.

For my designs, I design via a traditional data-path / controller design-flow. I know where my data is coming from and needs to go and I carefully design state machines that precisely, on a cycle-by-cycle basis define what happens in the circuit at all times. The "controller" sets up the data paths (via muxes) for each cycle so it is precisely know what the end functionality will be.

This is hardly "schematic entry" but I do know what the data path will look like before I enter the HDL. I must know or else I cannot guarantee that my implementation is optimal. I need to clock gigabytes worth off data through my FPGAs and need to squeeze out as much of the hardware as possible.

[T3sl4co1l]

Hmmm...

Am I perhaps correct in intuiting that "writing VHDL to implement RTL" is akin to assembly code, while "connecting high level blocks via VHDL" is akin to OOP?  -- With precisely the same optimization, development and philosophical argument issues in place?

Tim

[John_ITIC]

Hmmm...

Am I perhaps correct in intuiting that "writing VHDL to implement RTL" is akin to assembly code, while "connecting high level blocks via VHDL" is akin to OOP?  -- With precisely the same optimization, development and philosophical argument issues in place?

Tim

Yes, that's precisely it. And if you look at any new PC applications that are being implemented, the art of writing tight code is lost. Any application these days take up 10's of Megabytes for no reason other than that the macro tools generate loads of fluff that the implementer may not even be aware of. Of course, the savings is in implementation time. But for those cases where cycle-by-cycle precise control is needed (for any reason) assembly language is still alive.

I have worked as professional software developer for some 15 years and I see more and more that the newcomers have little to no understanding what goes on under the covers. The risk is the same with HDLs. An example is to design in SOCs on an FPGA just because it is available regardless whether it is suitable or needed. But I digress...

[kfnight]

Also, how come do the percentages add up to more than 100%  The imaginary purple (a.k.a.  "projected design language adoption trends within the next twelve months") figures add up to about 180% by my eyeball).

How can about 30% of designs be moving to SystemVerilog in one year, where the previous year's growth was 5%? That is like almost 1/3rd of all designs???

Numbers look either wrong, dodgy, out of context, or made for marketing purposes to me...

Hi Hamster. That is discussed in the original blog post. Many FPGA designs are mixed-language designs.

[Alexei.Polkhanov]

Altera people like Verilog, Xilinx people like VHDL. Just my impression, maybe wrong, but if you look at sample code in Quartus and ISE it seems to confirm that. I am not aware of design tool that supports _all_ SystemVerilog.

[slateraptor]

When I write VHDL, I approach it entirely from the angle of RTL.  What logic am I describing?  It starts with a logic diagram, then the implementation follows, and the synthesizer output is checked for correctness (and device operation, and inevitable debug cycles..).  When I talk VHDL with others, I find they regularly try to represent things as programmatical, which is fundamentally wrong; I always go directly to "what logic are you trying to synthesize?" -- and often get blank looks at an apparently alien approach!

That is -I'm sorry to say this- because they are right. Going at it from an RTL perspective entirely defeats the purpose of using an HDL. If you describe the function instead of the logic you'll get the job done in much less time and produce code which is much easier to understand, maintain and extend. I often need 3 lines of VHDL where others need 20.

Your method is like using Karnaugh diagrams to reduce logic equations by hand while the software tool which can do that for you in less than 1 second is right in front of you.

I have to agree with this.  If you're not taking advantage of the ability of the language to infer logic from behavioral descriptions, you might as well be doing schematic based designs. If you're not taking advantage of the language's strong typing, and as such using unsigned or signed or integers instead of std_logic_vector for math operations, you're making your life more difficult than necessary.

VHDL is very powerful, and modern synthesis tools really do take advantage of its features. You don't need to write RTL code to get excellent results.

Although I somewhat agree with your points, proper inference is really an advanced topic that requires intimate knowledge of both the synthesis tool and low-level constructs.

A software developer versed in high-level languages would likely not give a second glance at something seemingly harmless as c <= a + b;...yet knowing precisely what's synthesized (and why it doesn't work; alternative solutions) may very well mean the difference between 20 lines of code that satisfies cycle-accurate timing constraints or 3 lines of code that falls flat on its face. If you've ever had to interface with DRAM at a low level or other comparable high-speed application, these types of problems should be very familiar.

What strikes me as baffling is our unwavering infatuation with code brevity, even when it means sacrificing precise control and determinism. If that additional 17 lines of code means I'll be instantiating precisely what I want, that sounds like a small price to pay if I don't have to think twice about it and I save a single day in debug/integration. I feel like this is the fundamental disconnect that traditional software developers without a formal hardware background have when dabbling with HDL...all they see is the "L" part while abstracting away the "HD" to a higher domain (or pretend that it doesn't exist altogether) even when it doesn't make sense to do so.

Concerning math operations and numeric_std types, I'm sure Henry Warren has thought of more than few examples where std_logic_vector might make a little more sense in context.

Concerning Kmaps and logic optimization, I was told a story of the time an older CCA's logic was being mapped to a CPLD. Long story short, synthesis tool kept optimizing away gates specified in the original design. Turns out the OG design engineer was smart enough to mitigate combinatorial glitches caused by gate propagation delays using additional (unoptimized) logic...the synthesis tool (at the time?) wasn't. It wasn't until a manual Kmap analysis was performed that the OG design intent was made clear.

John_ITIC brings up a solid point about datapaths in FSM+D architectures. For any non-trivial pipeline that pushes the limits of a device's fabric, I'd approach the problem in a comparable way. But perhaps more importantly...

These hardware description languages are all tools and one should use the tool and abstraction level suitable for the job.