Little known in the industry, VHDL struct syntax allows for very neat and concise method to be used, called [Gaisler's method](<a href="http://www.gaisler.com/doc/vhdl2proc.pdf" rel="nofollow">http://www.gaisler.com/doc/vhdl2proc.pdf</a>). The entire Processor and architecture is written using it (<a href="http://www.gaisler.com/index.php/downloads/leongrlib" rel="nofollow">http://www.gaisler.com/index.php/downloads/leongrlib</a>) - and it is fantastic to work with - it feels like a piece of object oriented programming, while using low level language of VHDL. Not sure if anyone has tried to apply Gasler's method to SystemVerilog, but verilog on its own falls quite short in this regard.
VHDL and Verilog are virtually no different from eachother. It's basically equivalent to ARM assembly vs MIPS assembly -- they are both machine-level assembly languages.<p>If you want something more interesting, see High Level Synthesis (aka C to RTL, SystemC, etc) [1]. But this is still very beta (and has been for over a decade), so it's almost unused in the industry on designs.<p>The majority of hardware design time is now dominated in the hardware verification space, aka SystemVerilog.<p>[1] <a href="https://en.wikipedia.org/wiki/High-level_synthesis" rel="nofollow">https://en.wikipedia.org/wiki/High-level_synthesis</a>
Whenever the VHDL vs Verilog argument is brought up, I am reminded of this competition from a long time ago:<p><a href="http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/cooley.html" rel="nofollow">http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/...</a><p>(Notice which language won, who won, and what company he worked for...)
Verilog and VHDL are certainly fundamental, but there's plenty of alternatives...<p>Chisel with Scala, MyHDL with Python, Bluespec and Lava with Haskell are all low level HDL languages to name a few that piggy back on typical programming languages.<p>And if you want a higher level integrated solution you could use Altera OpenCL or Xilinx HLS.<p>Not to say we couldn't ask for a lot more from FPGA tools!!
Back many years ago when I had to make a choice between these two I took a very practical approach. I learned both of them to a level adequate enough to implement a few small test projects and then I made my decisions.<p>How?<p>As a solo founder CEO/CTO/Electrical, Mechanical, Software and FPGA Engineer and, let's not forget, Janitor at the time there was one thing I valued far above anything else: Time.<p>VHDL, I found, is very verbose. Verilog not so. To me this meant having to type twice as much to say the same thing. This didn't sit well with me and that was the primary driver in deciding in favor of Verilog.<p>Another driver was familiarity with C. I had a need to switch contexts with some frequency. I was using C and C++ for embedded and workstation code development. As a mental exercise, switching to VHDL felt, for lack of a better word, violent. Switching between those languages and Verilog felt natural. Again, a time saver.<p>It also seemed far easier to find and hire a good Verilog engineer when the time came for me to let go of that title and focus on being a better Janitor. To me Verilog was the clear winner on all fronts. At the time it lacked a few constructs that were later added into the language yet I never found that to be a problem and managed to successfully design and manufacture many successful products.
As a Haskell fan I was drawn toward VHDL because of its "strong typing". Haha, it's nothing like what I expected, mainly just a bunch of annoying forced casts from signed to unsigned etc. I ended up liking Verilog better: more characters are dedicated to your intent than to your casts. But ultimately they're not that different.<p>(Note there are also Haskell-oriented HDL's, but my experience with those wasn't great, at least 4-5 years ago. Proprietary, poor interop, and let's face it, it's not Haskell. On the surface FP seems like a good fit for FPGA, but in the trenches you constantly need lower-level tricks to keep your program's gate count from exploding.)
I'd say go with Verilog. SystemVerilog 2013 and VHDL 2008 are competitive when it comes to synthesis features, but synthesis is only half of the story.<p>SV's simulation features are really top-notch. If you're going to pick one to learn, I'd go with SV because you'll probably be using it anyways for verification tasks.
Both. The differences are not that great. I don't believe anyone who says they can done something in one that can't be done in another, they just don't now how to do it. After staring at a large design day after day, it is a pleasure to switch to the other one just to break up monotony. If you inherit someone else's design, I prefer to have the component list in VHDL to get an overall picture of what is going on. I guess it is easier to write Verilog, but easier to read someone else's VHDL.
At a recent Intel event I spoke to a senior Altera engineer and he recommended just using OpenCL and not bothering with either VHDL or Verilog. Apparently the OpenCL to FPGA compilers these days have become so good that the performance is within 10%-30% of hand-written VHDL / Verilog, which for most use-cases is very much in the "good enough" range.
Having used both for multiple years, I prefer Verilog. I think that for the synthesized subset of RTL, that HDL is typically used for, Verilog is way more productive than VHDL. The endless type conversions that are required for VHDL, just means too much mental burden and is away from actual design effort. VHDL is not practical.<p>Strong typing is useful when you use the same types for multiple instances, as in SW. However in HW, you construct your data to a set of bits, and then take as many as needed for the particular case. The type you need is a bit vector. Bit slicing checks can be done in the Linter tool, if needed. In DSP designs you can get benefits from VHDL types for signed and unsigned integers, but in my opinion even that does not cover the VHDL related deficiencies.<p>When you are working with synthesizable subset, you will never have problems with race conditions in simulation. You stick to a strict coding style, and it becomes the second nature. For beginners there are always issues, including this.<p>I find comparing the merits of SW languages to HW languages a bit silly. Describing SW does not benefit from the same features that describing HW does. For example Functional Programming (aka Haskell people) has nothing to do with HW. In FP you want to separate state from your functions. In HW the intention is to do the exact opposite. You want capture everything as local as possible, in order to enable maximum performance in speed, power, and area. This implies that OOP is pretty close to what HW requires, but not FP.
Try to implement a general purpose, synthesizable CRC for any polynomial of any size in Verilog without resorting to hard-coded lookup tables.<p>Can't be done.<p>One language suffers from a serious lack of expressiveness and forces its users to effectively carve their gates from stone with incessant low level bit twiddling. The other lets you describe high level behavior and have the tooling do all the hard work.
I've done both VHDL an Verilog extensively in school but not professionally. From my experience verilog was much nicer to use. I designed a complete MIPS pipelined CPU: <a href="https://github.com/eggie5/SDSU-COMPE475-SPRING13" rel="nofollow">https://github.com/eggie5/SDSU-COMPE475-SPRING13</a><p>However, speaking to many FPGA professionals I know, VHDL has a much more traction in industry and patricianly in defense contractors.
I recommend Clash. I've used it in production.<p><a href="http://www.clash-lang.org/" rel="nofollow">http://www.clash-lang.org/</a>