
VHDL or Verilog? - chclau
http://fpgasite.blogspot.com/2017/04/vhdl-or-verilog.html
======
mzakharo1
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
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/structure...](http://ens.ewi.tudelft.nl/Education/courses/et4351/structured_vhdl.pdf))

~~~
rektide
Slide 22 of this powerponit, Mike explicitly calls it Gaisler's Method. The
term he uses "Structured VHDL" comes next slide.

------
pdq
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)

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

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

~~~
wwwigham
HLS lets the compiler optimize your layouts for you more, since you're
expressing your algorithm's goals at a much higher level (and have left more
actual implementation details unspecified). I've implemented the same
algorithm in both HLS and Verilog and with a few pragmas the HLS code, the
result was infinitely more tweakable on the space/speed gradient - I was
pretty much able to utilize the maximal space I could to achieve maximal
execution speed - and limited to the same area I had used for the verilog
implementation, it had almost identical performance.

It's also incredibly time saving in that with HLS you can actually rapidly
unit test your designs (outside of a simulator), and you can usually get a
codegen for bindings for the SoC you're designing for so you don't have to
write any headers/interface code for the onboard processor yourself.

IMO, people who don't think HLS is a win either have years of experience
invested in older toolchains and are more productive with them (and don't see
HLS as worth their time), or haven't actually tried it.

I've mostly used a slightly hamstrung C++ as a HLS language with a Xilinx SoC.
C++ is infinitely nicer than an HDL, but I can't help but feel that Rust's
safety model more closely matches how an HLS wants to structure its
invariants, so I feel like it could be an excellent HLS language in the
future, given the chance.

~~~
bobsam
Having worked with a few variations that promised gold and delivered very
little, allow me disagree.

For complex designs I always came back crawling to vhdl and systemverilog.

(Jury is still out on Chisel, but it doesn't look good right now. Looks more
like it was designed by CS folks who just didn't get modern hardware design)

------
userbinator
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/...](http://athena.ecs.csus.edu/~changw/class_docs/VerilogManual/cooley.html)

(Notice which language won, who won, and what company he worked for...)

~~~
oelang
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
TL;DR:

1\. Guy worked for synopsis

2\. Unlike competition synopsis didn't have a vhdl product

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

~~~
fizixer
Thanks. I'll definitely give Migen a try. Looks like right up my creek.

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

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

~~~
rebootthesystem
You seem to be taking this personally. What I described was my reasoning for
choosing Verilog. It worked fine for me. I am not going to debate minutiae.

Also, who said Verilog is C? It feels like C but it isn't. It's simply a lot
easier to context switch between C and Verilog than between C and VHDL. That's
my opinion. You don't have to agree with it. There is no implicit obligation
to agree with anything at all.

I have shipped millions of dollars in product very successfully using Verilog.
Others have done so using VHDL. In the end it is a choice.

My intent was to give the OP one criteria he or she might be able to use in
some way in making a similar choice.

------
daxfohl
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
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
Geesh, does reporting my experience with the two languages really warrant this
kind of snarky ad-hominem attack?

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

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

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

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

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

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

------
deepnotderp
Neither, get yourself some Chisel.

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

------
eeks
OCaml with HardCaml
([http://www.ujamjar.com/hardcaml/](http://www.ujamjar.com/hardcaml/)).

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

------
tome
I recommend Clash. I've used it in production.

[http://www.clash-lang.org/](http://www.clash-lang.org/)

------
pjmlp
As Ada fan I would say VHDL.

------
codebook
Of course, systemverilog!

