I know this has been brought up many times in various groups but here is my view on them and I would really appreciate some clarification. I started working on FPGA design and stuff some 3 months back or so. All the time I was switching back and forth between verilog and VHDL for various projects. I personally feel that one can be very productive as in time with Verilog? I only use VHDL if there is no choice but I am not aganist VHDL or anything.
After some searching on google and various usenet groups I came across many arguments regarding Verilog vs VHDL summarising either as "use the right the tool for the right job" or "leading to language wars". I am open-minded and I am biased to the former at the same time a bit biased to verilog :) I just wanted to know some things.
-> Are there things that VHDL does better than verilog or vice-versa
-> What is the most widely used language in the industry i.e. FPGA and ASIC designs. I think VHDL is the dominant one as Xilinx totally uses VHDL?
All kinds of thoughts, experiences and constructive criticisms will be helpful.
Most Xilinx IP cores are delivered as VHDL for parameterization reasons, but we release a lot of Verilog code as well. Invariably when we release and application note with only one language we get an immediate request for the other.
Personally I prefer Verilog (I find it quicker to code and debug in than VHDL), but I've written just about as much VHDL.
VHDL was often said to be used more in Europe, DOD, and in the schools and now perhaps in FPGAs too.
I am always surprised to hear about Verilog use in schools or outside the US but I am biased to Verilog mostly because I use only a tiny fraction of the language anyway and come from the ASIC background.
At one time Verilog had a bulls eye mark on it by the EDA industry. The US ASIC guys had chosen Verilog and liked it enough because it had cell library support and could be mixed with C tools via the PLI. Verilog had been proprietary but when taken over by Cadence, it was released as an open standard. Phil Moorby had gone to Cadence along with his language and for awhile the entire EDA industry was going against Verilog and pronounced it as dead. Even Cadence people could only say Verilog under their breadth as politically incorrect. The customers eventually won out and atleast in the US Verilog still dominates in ASICs. It also helped that Synopsys took on Verilog for synthesis and pushed it forward no end. VHDl though came in right behind.
Trouble is as some will point out, ASIC starts are dying, FPGA designs are growing and the nature of design in both of these is quite different, huge teams v tiny teams, high risk v low risk.
In olden times, Verilog had alot more useablity at a low level for gate and device level modeling, which nobody really does anymore since synthesis took over.
VHDL always had advantages in higher level modelling. I think they overlapped by 70% but used different language constructs to say the same thing, Verilog generally used about half the key strokes.
Nowadays in the ASIC world Verilog is getting replaced by SuperLog now known as SystemVerilog which borrowed/stole several of VHDLs language features. I do wish Verilog could abandon some of its old features though and get light again.
Anyway the wars are really over, both the standards groups merged into one camp,. Officially both languages are merging in a way that neither could have predicted. Most EDA tools have 2 parsers in front end and a common language internal engine. Its more hassle to support this but it will go on for some time.
I see Verliog getting more and more replaced by SystemVerilog. WIth SV you enable Verilog designer to do everything you could do with VHDL including the most disadvantage of VHDL: writing bad code.
A more detailed view is availabel under
or in several other discussions around the web. On a first glance you gain abstraction levels by walking along Verilog -> VHDL -> SystemVerilog -> SystemC Each gain in abstraction level costs you more effort to ensure your code is not too abstract for your task.
Here be dragons and I should perhaps not jump into the dragon pit, but here's an observation:
One thing I notice is that people who have had exposure to software development seem to prefer VHDL because VHDL allows one to define new types whereas with Verilog you've gotta be happy with the types that come with it out-of-the-box. Hardware engineers with lots of software background might therefore tend to prefer VHDL whereas Hardware engineers with less software development experience might tend to prefer Verilog because they may not care about the potential benefits of being able to define new types.
I think it just goes way back to when Verilog first came out, we were still driven by schematics in the early 80s, the nested symbol was the level of abstraction used.
Verilog was primary invented by Moorby when he joined Gateway. On day one he was told they had a synthesis tool with no language to drive it, so he insisted on building one. He had previously built the Hilo tool for Genrad so he had a good insight as to what was needed at that time.
It may be true that in the past hardware guys with little software experience didn't care about having such abstractions available since the divide was far greater then, but the opposite point can't always be true. When you are proficient in software and hardware you can still choose Verilog over VHDL because the missing abstractions can be got by working in C or other languages. Most projects involve both hardware & software and Verilog + something else was able to make up for the missing features that VHDL had.
I wonder what programming languages VHDL fans generally favor, is it just same as everyone else? Does VHDL generally need C or anything to boost it in anyway?
As a retired computer programmer of 35+ years who has only recently taught myself Verilog during my retirement (as a hobby), I vastly prefer Verilog to what I've seen of VHDL.
On the other hand, most of my programming was "down to the metal" device drivers and realtime embedded systems work, so it was very important for me to be able to easily deal with hardware interfaces and to know exactly what code the compiler (if used at all) generated so I could have strict control over the timing of things. I was overjoyed when the C programming language came along because it maps very well to the computer architectures of most machines and allowed me to use a high level language instead of assembly language even when doing bit-twiddling things such as device drivers (I had used assembly and Pascal up until then). The transition from C to Verilog was almost totally painless once I figured out this new concept of "wires" ;-) because of the similarity between the two languages - at least as far as the low level operators and general design philosophy of the languages go.
The thing that bothers me most about abstract computer languages such as COBOL, Lisp, ADA, and I will include VHDL in this category) is that the hardware the design is implemented on is *not* abstract at all - it is composed of bits and bytes and elementary operations an ALU can perform, and so if I care anything at all about performance I like to use a relatively low level language.
I think it's rather amusing that whenever I do a new Verilog design, I usually begin by coding the algorithm in the Maple computer language. Maple is a very high level arbitrary precision language that can do symbolic algebra, calculus, differential equations, etc. It may be a surprising choice as a design language for Verilog, but it works quite well because Maple allows me to do pretty much whatever I want without regard to implementation specifics. When I wrote the Verilog implementation of Lenstra's Elliptic Curve Factoring method (ECM), I started by writing a Maple program from the algorithm described in a textbook, and then gradually decomposed each of the higher level operations into simpler operations until I had something that could be implemented easily in Verilog. :-)
P.S. My Verilog ECM factoring design for the RSA-704 challenge number is now in its 178'th hour of synthesis (CPU hours), and shows no signs of finishing any time soon. I'm using Xilinx 5.1 Foundation software targeted at a Xilinx XCV2000E FPGA, and running on a Pentium 4 with 1.5 GB of RAM.
The thing about VHDL is that although it has some highish levels of abstraction, which are great for the test environment. However, if you are writing synthesisable code, you are much more constrained, and the language maps relatively predictably (most of the time) onto device hardware. So you get the best of both worlds.
IMHO There's no *design performance* reason to prefer Verilog over VHDL. At the RTL level they are pretty much equivalent nowadays (as I understand it, I'm predominantly a VHDL man myself)
That's always a good way to proceed :-)
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
I dont unstand what you are saying, Ron. You are a Verilog novice and don't know VHDL. You may have 35+ years of "experience", but that doesn't make you more credible in this particular context
If your C and Verilog are very close to each other, then something is very wrong. Ignoring the HW vs SW-mind, yes the syntax is kind of resembling. But after 35+ years you should be able to learn any syntax in a day or two?
Do you seriously mean that you choose Verilog over VHDL because you couldn't learn to write "AND" instead of "&"?
(BTW, I am a C programmer by trade. Wondering my favourite HDL? read on then...)
*Everything* is abstract, at some level and with some distance...
If you haven't seen it yet, its because you are playing with tiny designs (knowning your answer here, I counter: yes, you can still fill a large FPGA with a tiny design). And for gods sake, how did you - as a software guy - missed the big "abstraction wave" during the 90s?
You said you prefer C over assembler. Well, same thing here. Please read up on behavioural-but-still-synthesizable-code.
Given the current state of synthesis tools, I prefer to write code at a higher level and let Synplify/DC/Leonardo/Quartus/Blast/Palace do their magic. Somehow, I don't feel like doing multimillion-gate designs at transistor level.
Now you are contradicting yourself. I use C-based languages (C/C++/Java/C#/..) to prototype. I may use Matlab when I do DSP, but thats another story.
I know VHDL, Verilog and SystemC plus a few more (there were tons of other languages during the PAL/PLD-era). And believe me, they are all pretty much the same, SPECIALLY AT LOW-LEVEL!
language V2 do it because they don't know language V2. Given that VHDL is a bit harder to learn, you hear a lot of this from the Verilog-Only camp. And then you have the ASIC people who love to hate VHDL. But Austin and Peter say ASIC is dying, and given that they are one of world largest AISC shops I assume they know what they are talking about :)
Ok back to the subject, if you are serious about HW design, you MUST know at least VHDL and Verilog. Well, unless you never ever use IP-blocks, which is a whole another discussion...
Austin Lesea ( firstname.lastname@example.org) wrote: : All,
: So, if you are wondering if you should learn verilog or VHDL, the : figures really say you should know both. Well. Really well.
(Going of on a tanget here from the bulk of Austin's posting...!)
Hah. I get a bit bored seeign the repetative 'Should I learn VHDL or Verilog' questions. Both are a bit more nebulous than most software languages people learn, in that everyone's synthesis or simulation tools implement different parts of the language spec for different purposes, and ultimatly most people on CAF use them to describe what they want a CPLD/FPGA to do. Chuck in the mess of things like VHDL attributes and Verilog comments being used to pass (vendor / technology) specific hints to the synthesiser...
When that's the case what you really need to know is what you want the device to do, how the device works best, and the intersection between the two. If you've got half a clue about that and are competent in any computer language then VHDL/Verilog become little more than a preference for a syntax (other than generate + attributes etc. in rare cases.)
And both could be much better. Much much better. Oh well...