7 ms·

VHDL or Verilog?

115 points by chclau 9y ago

pdq 9y ago
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. 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. The majority of hardware design time is now dominated in the hardware verification space, aka SystemVerilog. [1] https://en.wikipedia.org/wiki/High-level_synthesis https://en.wikipedia.org/wiki/High-level_synthesis
- chclau 9y ago
  On the last releases of Vivado, Xilins is making a big push for HLS. Personally I have not still had the chance to learn and try it.
- beagle3 9y ago
  I last did either VHDL or Verilog in 1997, which is 20 years ago (and reminds me I'm getting old), but if things are remotely similar, the apt comparison is not ARM assembly vs. MIPS assembly, but rather Verilog=~C vs VHDL=~Ada
  - chclau 9y ago
    I don't know ADA, I have always thought that Verilog is like old C and VHDL like C++. Not that VHDL is object oriented, but is a strong-typed language.
    - beagle3 9y ago
      VHDL's syntax was borrowed from Ada (and much more closely resembles it than Verilog, which was inspired by C but not adapted from it) Example Ada: http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada
    - ajdlinux 9y ago
      VHDL's syntax and type system are quite Ada-ish, from what I gather.
    - oelang 9y ago
      VHDL is an old version of ADA combined with a build-in discrete event simulator. The syntax, type system, general semantics are all copied from ADA. This is actually a good thing, Verilog (and even more SystemVerilog) is designed by people who don't have a clue about language design resulting in an incredible mess of a language.
- microcolonel 9y ago
  I think there is room for something in-between. High-level synthesis is probably never going to meet the needs of most ASIC designers, especially as progress on manufacturing processes has effectively stopped. The more promising avenue to me is structured synthesis: using straightforward abstraction but keeping the HDL model. Chisel (based in Scala) seems to be the biggest open source one; bluespec is a more established run at the same concept which is based in Haskell, and interestingly they seem to be throwing all of their marketing weight behind RISC-V solutions. So in a way, high-level functional HDL is dominated by RISC-V today.
  - codebook 9y ago
    I have doubt that RISC-V will take visible portion of mobile/embedded core any time soon. It was announced 6 years ago as far as I know but still only few commercial products have it inside. Chiesel itself would be sunken together since it uses RISC-V as a ad.
    - microcolonel 9y ago
      At least embedded seems to be embracing RISC-V like it's a race. Microsemi markets RISC-V tooling, Lattice semiconductor markets it, and basically all of Bluespec's marketing material is around their RISC-V development tools (for formal and differential verification of new RISC-V cores). NVIDIA is already embedding RISC-V deeply into every one of their chipsets (all Tegras, all mobile discrete GPUs, all desktop discrete GPUs). I don't see how somebody with any knowledge of the embedded industry could conclude that RISC-V will fail to penetrate that market. As for consumer mobile devices, such as smartphones and tablets, you could make the argument that ARM has a lot of traction. However, the cost and flexibility benefits of RISC-V are not moot. For platforms like the Chromebook, you have a lot more flexibility in terms of the hardware platform. There's no practical reason why RISC-V would fail in Chromebooks. Workstations, desktops, and general purpose (usually windows) laptops are a lot tougher. There is a lot of consumer value in the dominance of x86 in these markets so I probably wouldn't expect much to budge there in a short amount of time. As for servers, however, there is no strict reason why any new ISA would fail. The biggest handicaps would be lack of out-of-the box distro support, platform inconsistency (huge problem for ARM, where you can't generally share images between boards), and low quality of compilers and language runtimes. If there is a good JVM port, a good v8 port, a good GCC port, and a good LLVM port, and maybe a few other VMs (like BEAM), there is no reason why RISC-V would be doomed to fail on servers. In fact, I see huge reasons why RISC-V would win the server market. Imagine an SoC which has the ethernet MAC, the remote management system/iKVM (with low-level access to the platform serial console) and a big wide superscalar OoO for running your server application on it. Imagine that the clean separation of ABI, SBI, HBI, and MBI drives up the quality, isolation guarantees, and performance of virtual machines. Imagine that you could have a TPU on the same die as the application processor, with a low-latency preemptible interconnect and unified memory. I see RISC-V's technical decisions as almost uniquely suitable for the server market, and I think the server market is probably the most amenable to new ISA penetration.
- odmkSeijin 9y ago
  I programmed FPGAs using both VHDL and Verilog for many years. Recently I have started at a start-up where we predominantly program using C++ HLS. I never want to go back to full-time HDL again. We have found it is possible to get the same performance as carefully written RTL, but you still have to write with the underlying device architecture in mind. There are advantages with HLS, simulation is vastly faster, and C++ templates can be used. This makes it easy to try many iterations and find clever optimizations. If you try to do the same with HDL it would be a nightmare with a large design. More people should move to HLS and push for the tools to improve. the world would be a better place.
  - orbifold 9y ago
    What tool do you use for this? Also, are you targeting ASICS or FPGAs? I think for ASICs there are probably a ton of custom non-public tools that use C++, one is for example described in http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf, the Mill Architecture people seem to plan the same, but I haven't seen any in the open so far.
  - oelang 9y ago
    Be honest though, HLS works well for DSP-like applications, not for anything else. Not every digital design is image processing and if it works well you're still sacrificing ~20% of your LUTs.
    - odmkSeijin 9y ago
      I don't agree with this, but I think I see what you are trying to say. I think typically a full design would include some interface portion with maybe DMA or PCIe or whatever that would be done in HDL, and maybe a processor or not. HLS works for the processing that is done inside the FPGA. If this is what you mean by DSP-like, then sure, but it does not have to be image processing, it could be anything done in fabric. It is possible to write a specific truth-table, and similar basic elements in C++, so why would you be forced to do any specific type of application? Where did you get %20 percent number? At least for Xilinx HLS, I don't think that has anything to do with anything (maybe for some other compiler??). If you take some generic C or C++ code and try to put it in an FPGA, the number will be more like 80%. The results will be horrible. On the other hand, if you write code in a way that naturally maps to the hardware you are using then the results can be every bit as good RTL. But this is not necessarily easy to do. I think that this has more to do with the quality of the current compilers, not some inherent limitation with the concept. I like HDL, but I would much much rather program in C++. It is a more sophisticated language. I think Intel/Altera is supposed to release some HLS tool, and I know there are others that I haven't tried. What I am saying is that it would be nice if enough effort was put into these tools to not have to worry about whether there are limitations. Even more so since I think the newer C++ standards are moving towards multi-threading/concurrency.
mars4rp 9y ago
Verilog of course. try to do nested if without else in VHDL!
deepnotderp 9y ago
Neither, get yourself some Chisel.
jackyinger 9y ago
Verilog and VHDL are certainly fundamental, but there's plenty of alternatives... 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. And if you want a higher level integrated solution you could use Altera OpenCL or Xilinx HLS. Not to say we couldn't ask for a lot more from FPGA tools!!
- fizixer 9y ago
  I'm hoping to try MyHDL someday. If it's good, great, otherwise probably I'll try to develop my own metaprogramming (likely based on R7RS scheme) system on top of VHDL.
  - q3k 9y ago
    When it comes to Python 'frontends'/'preprocessors'/'high-level-synthesis tools' I prefer Migen over MyHDL, mostly because of the vastly different abstraction level. MyHDL parses a normal Python AST and translates it to Verilog statements. In the end, you seem to end up with the exactly same abstraction layer as Verilog/VHDL, just with a Python syntax. There is a very limited subset of advanced Python composability constructs you can use without hitting a limitation of the AST walker and translator. And when you do hit it, it's fairly annoying to debug. In the end, I don't see it's use over writing straight Verilog/VHDL, apart from it being easier to test. Migen, on the other hand, is a system where you write native Python code that doesn't pretend to be then running on the FPGA. Instead, your code stitches together an RTL AST, which can then be either simulated or converted to Verilog. Your Python code is effectively a RTL logic generator (AFAIK this is exactly how Chisel/SpinalHDL work, too). You can then compose these low-level constructs into higher layer abstractions- for instance, the stock Migen framework comes with an FSM abstractions, which takes care of all the boilerplate if declaring state machines (state register and values, separate synchronous/combinatorial logic statements, etc.). It also comes with abstractions for Arrays, (B)RAM, FIFOs, priority encoders... Finally, Migen is the base of the MiSoC project, which abstracts away enough digital logic to let you connect, in Python, high-level constructs like buses, CPUs, DRAM controllers, etc. in order to dynamically construct a system-on-chip.
nrclark 9y ago
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. 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.
rebootthesystem 9y ago
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. How? 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. 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. 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. 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.
- chclau 9y ago
  For many years now I have been using mainly Altera and VHDL. Lately I started a new job and returned to Xilinx which I have not used for long. Part of my job is integrating three major IPs, and guess what? One of them is VHDL and two others are Verilog. So yes, sure, you can wrap a Verilog code with VHDL and forget it... but, the Verilog IPs come also with their Verilog testbenches, etc. So for me it will be a bilingual reality for some time to come.
- oelang 9y ago
  The verbosity of VHDL isn't 2x it's more like 20% bigger on average and since VHDL 2008 it's pretty much the same. VHDL can be wordy but it also reads a lot easier & it looks more structured. Verilog isn't C, it's C-ish, just different enough to make me make mistakes all the time like 'not' in verilog is '~' instead of '!', or the lack of overloading, the weird rules with signed & unsigned numbers and the implicit wire declarations etc. Verilog is full of surprises. Do you like determinism? Have you ever tried running the same (System)Verilog design on multiple simulators? Almost every time you get different results, VHDL doesn't have this issue.
pjmlp 9y ago
As Ada fan I would say VHDL.
odmkSeijin 9y ago
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.
eeks 9y ago
OCaml with HardCaml (http://www.ujamjar.com/hardcaml/ http://www.ujamjar.com/hardcaml/).
userbinator 9y ago
Whenever the VHDL vs Verilog argument is brought up, I am reminded of this competition from a long time ago: http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/cooley.html http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/... (Notice which language won, who won, and what company he worked for...)
- oelang 9y ago
  This is a very old (I think > 15 years ago) competition, the results say nothing about the situation today, both language have changed a lot. It was a PR stunt by the Synopsys guys who a that time wanted to kill VHDL. The VHDL guys had to work with slow & broken VHDL simulators. The the problem was devised by verilog enthusiasts. All VHDL engineers who showed up (in much smaller numbers than verilog engineers) felt like they they didn't have a fair chance.
  - bobsam 9y ago
    TL;DR: 1. Guy worked for synopsis 2. Unlike competition synopsis didn't have a vhdl product
- bobsam 9y ago
  This poat was heavily cirticized when it was published. For the language subset needed for this test, the languages are EQUAL (different syntax, same structure and outcome). Also, the guy who run the competition (and his employer) have for years tried to kill vhdl (for personal and $$$ reasons).
rsp1984 9y ago
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.
- oelang 9y ago
  No they haven't and they are not even close. OpenCL is a bad language for synthesis. The strength of an FPGA is deeply-pipeline-able sequential algorithms. C-based languages just aren't good at expressing/controlling pipelining, so the synthesizer/compiler has to infer this but that problem is too hard. You could change 1 line of code, a minor fixup and the clever optimizer fails and your design is suddenly 10x as big.
- kingosticks 9y ago
  If you're happy to throw away up to 30% of your performance I think you've got to question why you're designing hardware, even on FPGAs. It probably is good news for Altera as you'll now need a higher spec device to solve your problem.
daxfohl 9y ago
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. (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.)
- oelang 9y ago
  Let me guess, you were downcasting everything to std_logic_vector? If you have to cast things all the time in VHDL you're not using it correctly. But please enjoy (System)Verilog with it's random often undefined coercion, implicit wire declarations, non-deterministic simulation and lack of any meaningful compile-time checks. Honestly, as a huge Haskell fan, I can't believe you're a Haskell fan.
  - daxfohl 9y ago
    Geesh, does reporting my experience with the two languages really warrant this kind of snarky ad-hominem attack?
sunmag 9y ago
Vhdl + vunit. HLS will (latency/bandwidth)-wise do equally good, provided you have some spare resources(large enough fpga).
mzakharo1 9y ago
Little known in the industry, VHDL struct syntax allows for very neat and concise method to be used, called [Gaisler's method](http://www.gaisler.com/doc/vhdl2proc.pdf http://www.gaisler.com/doc/vhdl2proc.pdf). The entire Processor and architecture is written using it (http://www.gaisler.com/index.php/downloads/leongrlib http://www.gaisler.com/index.php/downloads/leongrlib) - 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.
- krapht 9y ago
  Was Gaisler the first to write about it? I actually first heard about it from Mike Treseler, who is mentioned in this Powerpoint (http://ens.ewi.tudelft.nl/Education/courses/et4351/structured_vhdl.pdf http://ens.ewi.tudelft.nl/Education/courses/et4351/structure...)
  - rektide 9y ago
    Slide 22 of this powerponit, Mike explicitly calls it Gaisler's Method. The term he uses "Structured VHDL" comes next slide.
eggie5 9y ago
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: https://github.com/eggie5/SDSU-COMPE475-SPRING13 https://github.com/eggie5/SDSU-COMPE475-SPRING13 However, speaking to many FPGA professionals I know, VHDL has a much more traction in industry and patricianly in defense contractors.
kevin_thibedeau 9y ago
Try to implement a general purpose, synthesizable CRC for any polynomial of any size in Verilog without resorting to hard-coded lookup tables. Can't be done. 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.
- nrclark 9y ago
  I actually did this exact thing in Verilog at a former employer, and got pretty good results (at least with the Xilinx toolchain). It just took some creative use of Verilog's 'function' construct. The basic structure was: 1. Write a function that calculated the next bit from a the existing state and the target poly. 2. Write a second function that called that first function repeatedly (once per bit in the target word). 3. Call the second function on the input data for a combinatorial output.
codebook 9y ago
Of course, systemverilog!
tisannai 9y ago
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. 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. 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. 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.
tome 9y ago
I recommend Clash. I've used it in production. http://www.clash-lang.org/ http://www.clash-lang.org/

115 points by chclau 9y ago

pdq 9y ago

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. 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. The majority of hardware design time is now dominated in the hardware verification space, aka SystemVerilog. [1] https://en.wikipedia.org/wiki/High-level_synthesis https://en.wikipedia.org/wiki/High-level_synthesis

chclau 9y ago
On the last releases of Vivado, Xilins is making a big push for HLS. Personally I have not still had the chance to learn and try it.
beagle3 9y ago
I last did either VHDL or Verilog in 1997, which is 20 years ago (and reminds me I'm getting old), but if things are remotely similar, the apt comparison is not ARM assembly vs. MIPS assembly, but rather Verilog=~C vs VHDL=~Ada
- chclau 9y ago
  I don't know ADA, I have always thought that Verilog is like old C and VHDL like C++. Not that VHDL is object oriented, but is a strong-typed language.
  - beagle3 9y ago
    VHDL's syntax was borrowed from Ada (and much more closely resembles it than Verilog, which was inspired by C but not adapted from it) Example Ada: http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada http://perso.telecom-paristech.fr/~pautet/Ada95/e_c16_p5.ada
  - ajdlinux 9y ago
    VHDL's syntax and type system are quite Ada-ish, from what I gather.
  - oelang 9y ago
    VHDL is an old version of ADA combined with a build-in discrete event simulator. The syntax, type system, general semantics are all copied from ADA. This is actually a good thing, Verilog (and even more SystemVerilog) is designed by people who don't have a clue about language design resulting in an incredible mess of a language.
microcolonel 9y ago
I think there is room for something in-between. High-level synthesis is probably never going to meet the needs of most ASIC designers, especially as progress on manufacturing processes has effectively stopped. The more promising avenue to me is structured synthesis: using straightforward abstraction but keeping the HDL model. Chisel (based in Scala) seems to be the biggest open source one; bluespec is a more established run at the same concept which is based in Haskell, and interestingly they seem to be throwing all of their marketing weight behind RISC-V solutions. So in a way, high-level functional HDL is dominated by RISC-V today.
- codebook 9y ago
  I have doubt that RISC-V will take visible portion of mobile/embedded core any time soon. It was announced 6 years ago as far as I know but still only few commercial products have it inside. Chiesel itself would be sunken together since it uses RISC-V as a ad.
  - microcolonel 9y ago
    At least embedded seems to be embracing RISC-V like it's a race. Microsemi markets RISC-V tooling, Lattice semiconductor markets it, and basically all of Bluespec's marketing material is around their RISC-V development tools (for formal and differential verification of new RISC-V cores). NVIDIA is already embedding RISC-V deeply into every one of their chipsets (all Tegras, all mobile discrete GPUs, all desktop discrete GPUs). I don't see how somebody with any knowledge of the embedded industry could conclude that RISC-V will fail to penetrate that market. As for consumer mobile devices, such as smartphones and tablets, you could make the argument that ARM has a lot of traction. However, the cost and flexibility benefits of RISC-V are not moot. For platforms like the Chromebook, you have a lot more flexibility in terms of the hardware platform. There's no practical reason why RISC-V would fail in Chromebooks. Workstations, desktops, and general purpose (usually windows) laptops are a lot tougher. There is a lot of consumer value in the dominance of x86 in these markets so I probably wouldn't expect much to budge there in a short amount of time. As for servers, however, there is no strict reason why any new ISA would fail. The biggest handicaps would be lack of out-of-the box distro support, platform inconsistency (huge problem for ARM, where you can't generally share images between boards), and low quality of compilers and language runtimes. If there is a good JVM port, a good v8 port, a good GCC port, and a good LLVM port, and maybe a few other VMs (like BEAM), there is no reason why RISC-V would be doomed to fail on servers. In fact, I see huge reasons why RISC-V would win the server market. Imagine an SoC which has the ethernet MAC, the remote management system/iKVM (with low-level access to the platform serial console) and a big wide superscalar OoO for running your server application on it. Imagine that the clean separation of ABI, SBI, HBI, and MBI drives up the quality, isolation guarantees, and performance of virtual machines. Imagine that you could have a TPU on the same die as the application processor, with a low-latency preemptible interconnect and unified memory. I see RISC-V's technical decisions as almost uniquely suitable for the server market, and I think the server market is probably the most amenable to new ISA penetration.
odmkSeijin 9y ago
I programmed FPGAs using both VHDL and Verilog for many years. Recently I have started at a start-up where we predominantly program using C++ HLS. I never want to go back to full-time HDL again. We have found it is possible to get the same performance as carefully written RTL, but you still have to write with the underlying device architecture in mind. There are advantages with HLS, simulation is vastly faster, and C++ templates can be used. This makes it easy to try many iterations and find clever optimizations. If you try to do the same with HDL it would be a nightmare with a large design. More people should move to HLS and push for the tools to improve. the world would be a better place.
- orbifold 9y ago
  What tool do you use for this? Also, are you targeting ASICS or FPGAs? I think for ASICs there are probably a ton of custom non-public tools that use C++, one is for example described in http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf http://scale.eecs.berkeley.edu/papers/krashinsky-phd.pdf, the Mill Architecture people seem to plan the same, but I haven't seen any in the open so far.
- oelang 9y ago
  Be honest though, HLS works well for DSP-like applications, not for anything else. Not every digital design is image processing and if it works well you're still sacrificing ~20% of your LUTs.
  - odmkSeijin 9y ago
    I don't agree with this, but I think I see what you are trying to say. I think typically a full design would include some interface portion with maybe DMA or PCIe or whatever that would be done in HDL, and maybe a processor or not. HLS works for the processing that is done inside the FPGA. If this is what you mean by DSP-like, then sure, but it does not have to be image processing, it could be anything done in fabric. It is possible to write a specific truth-table, and similar basic elements in C++, so why would you be forced to do any specific type of application? Where did you get %20 percent number? At least for Xilinx HLS, I don't think that has anything to do with anything (maybe for some other compiler??). If you take some generic C or C++ code and try to put it in an FPGA, the number will be more like 80%. The results will be horrible. On the other hand, if you write code in a way that naturally maps to the hardware you are using then the results can be every bit as good RTL. But this is not necessarily easy to do. I think that this has more to do with the quality of the current compilers, not some inherent limitation with the concept. I like HDL, but I would much much rather program in C++. It is a more sophisticated language. I think Intel/Altera is supposed to release some HLS tool, and I know there are others that I haven't tried. What I am saying is that it would be nice if enough effort was put into these tools to not have to worry about whether there are limitations. Even more so since I think the newer C++ standards are moving towards multi-threading/concurrency.

mars4rp 9y ago

Verilog of course. try to do nested if without else in VHDL!

deepnotderp 9y ago

Neither, get yourself some Chisel.

jackyinger 9y ago

Verilog and VHDL are certainly fundamental, but there's plenty of alternatives... 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. And if you want a higher level integrated solution you could use Altera OpenCL or Xilinx HLS. Not to say we couldn't ask for a lot more from FPGA tools!!

fizixer 9y ago
I'm hoping to try MyHDL someday. If it's good, great, otherwise probably I'll try to develop my own metaprogramming (likely based on R7RS scheme) system on top of VHDL.
- q3k 9y ago
  When it comes to Python 'frontends'/'preprocessors'/'high-level-synthesis tools' I prefer Migen over MyHDL, mostly because of the vastly different abstraction level. MyHDL parses a normal Python AST and translates it to Verilog statements. In the end, you seem to end up with the exactly same abstraction layer as Verilog/VHDL, just with a Python syntax. There is a very limited subset of advanced Python composability constructs you can use without hitting a limitation of the AST walker and translator. And when you do hit it, it's fairly annoying to debug. In the end, I don't see it's use over writing straight Verilog/VHDL, apart from it being easier to test. Migen, on the other hand, is a system where you write native Python code that doesn't pretend to be then running on the FPGA. Instead, your code stitches together an RTL AST, which can then be either simulated or converted to Verilog. Your Python code is effectively a RTL logic generator (AFAIK this is exactly how Chisel/SpinalHDL work, too). You can then compose these low-level constructs into higher layer abstractions- for instance, the stock Migen framework comes with an FSM abstractions, which takes care of all the boilerplate if declaring state machines (state register and values, separate synchronous/combinatorial logic statements, etc.). It also comes with abstractions for Arrays, (B)RAM, FIFOs, priority encoders... Finally, Migen is the base of the MiSoC project, which abstracts away enough digital logic to let you connect, in Python, high-level constructs like buses, CPUs, DRAM controllers, etc. in order to dynamically construct a system-on-chip.

nrclark 9y ago

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. 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.

rebootthesystem 9y ago

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. How? 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. 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. 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. 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.

chclau 9y ago
For many years now I have been using mainly Altera and VHDL. Lately I started a new job and returned to Xilinx which I have not used for long. Part of my job is integrating three major IPs, and guess what? One of them is VHDL and two others are Verilog. So yes, sure, you can wrap a Verilog code with VHDL and forget it... but, the Verilog IPs come also with their Verilog testbenches, etc. So for me it will be a bilingual reality for some time to come.
oelang 9y ago
The verbosity of VHDL isn't 2x it's more like 20% bigger on average and since VHDL 2008 it's pretty much the same. VHDL can be wordy but it also reads a lot easier & it looks more structured. Verilog isn't C, it's C-ish, just different enough to make me make mistakes all the time like 'not' in verilog is '~' instead of '!', or the lack of overloading, the weird rules with signed & unsigned numbers and the implicit wire declarations etc. Verilog is full of surprises. Do you like determinism? Have you ever tried running the same (System)Verilog design on multiple simulators? Almost every time you get different results, VHDL doesn't have this issue.

pjmlp 9y ago

As Ada fan I would say VHDL.

odmkSeijin 9y ago

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.

eeks 9y ago

OCaml with HardCaml (http://www.ujamjar.com/hardcaml/ http://www.ujamjar.com/hardcaml/).

userbinator 9y ago

Whenever the VHDL vs Verilog argument is brought up, I am reminded of this competition from a long time ago: http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/cooley.html http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/... (Notice which language won, who won, and what company he worked for...)

oelang 9y ago
This is a very old (I think > 15 years ago) competition, the results say nothing about the situation today, both language have changed a lot. It was a PR stunt by the Synopsys guys who a that time wanted to kill VHDL. The VHDL guys had to work with slow & broken VHDL simulators. The the problem was devised by verilog enthusiasts. All VHDL engineers who showed up (in much smaller numbers than verilog engineers) felt like they they didn't have a fair chance.
- bobsam 9y ago
  TL;DR: 1. Guy worked for synopsis 2. Unlike competition synopsis didn't have a vhdl product
bobsam 9y ago
This poat was heavily cirticized when it was published. For the language subset needed for this test, the languages are EQUAL (different syntax, same structure and outcome). Also, the guy who run the competition (and his employer) have for years tried to kill vhdl (for personal and $$$ reasons).

rsp1984 9y ago

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.

oelang 9y ago
No they haven't and they are not even close. OpenCL is a bad language for synthesis. The strength of an FPGA is deeply-pipeline-able sequential algorithms. C-based languages just aren't good at expressing/controlling pipelining, so the synthesizer/compiler has to infer this but that problem is too hard. You could change 1 line of code, a minor fixup and the clever optimizer fails and your design is suddenly 10x as big.
kingosticks 9y ago
If you're happy to throw away up to 30% of your performance I think you've got to question why you're designing hardware, even on FPGAs. It probably is good news for Altera as you'll now need a higher spec device to solve your problem.

daxfohl 9y ago

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. (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.)

oelang 9y ago
Let me guess, you were downcasting everything to std_logic_vector? If you have to cast things all the time in VHDL you're not using it correctly. But please enjoy (System)Verilog with it's random often undefined coercion, implicit wire declarations, non-deterministic simulation and lack of any meaningful compile-time checks. Honestly, as a huge Haskell fan, I can't believe you're a Haskell fan.
- daxfohl 9y ago
  Geesh, does reporting my experience with the two languages really warrant this kind of snarky ad-hominem attack?

sunmag 9y ago

Vhdl + vunit. HLS will (latency/bandwidth)-wise do equally good, provided you have some spare resources(large enough fpga).

mzakharo1 9y ago

Little known in the industry, VHDL struct syntax allows for very neat and concise method to be used, called [Gaisler's method](http://www.gaisler.com/doc/vhdl2proc.pdf http://www.gaisler.com/doc/vhdl2proc.pdf). The entire Processor and architecture is written using it (http://www.gaisler.com/index.php/downloads/leongrlib http://www.gaisler.com/index.php/downloads/leongrlib) - 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.

krapht 9y ago
Was Gaisler the first to write about it? I actually first heard about it from Mike Treseler, who is mentioned in this Powerpoint (http://ens.ewi.tudelft.nl/Education/courses/et4351/structured_vhdl.pdf http://ens.ewi.tudelft.nl/Education/courses/et4351/structure...)
- rektide 9y ago
  Slide 22 of this powerponit, Mike explicitly calls it Gaisler's Method. The term he uses "Structured VHDL" comes next slide.

eggie5 9y ago

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: https://github.com/eggie5/SDSU-COMPE475-SPRING13 https://github.com/eggie5/SDSU-COMPE475-SPRING13 However, speaking to many FPGA professionals I know, VHDL has a much more traction in industry and patricianly in defense contractors.

kevin_thibedeau 9y ago

Try to implement a general purpose, synthesizable CRC for any polynomial of any size in Verilog without resorting to hard-coded lookup tables. Can't be done. 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.

nrclark 9y ago
I actually did this exact thing in Verilog at a former employer, and got pretty good results (at least with the Xilinx toolchain). It just took some creative use of Verilog's 'function' construct. The basic structure was: 1. Write a function that calculated the next bit from a the existing state and the target poly. 2. Write a second function that called that first function repeatedly (once per bit in the target word). 3. Call the second function on the input data for a combinatorial output.

codebook 9y ago

Of course, systemverilog!

tisannai 9y ago

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. 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. 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. 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.

tome 9y ago

I recommend Clash. I've used it in production. http://www.clash-lang.org/ http://www.clash-lang.org/