Slashdot Mirror
VHDL or Verilog For Learning FPGAs?
FlyByPC writes "We're in the first stages of designing a course in programmable devices at the university where I work. The course will most likely be centered around various small projects implemented on an FPGA dev board, using a Xilinx Spartan3-series FPGA. I have a bit of experience working with technologies from 7400-series chips (designing using schematics) to 8-bit microcontrollers to C/C++. FPGAs, though, are new to me (although they look very interesting.) If you were an undergraduate student studying programmable devices (specifically, FPGAs), would you prefer the course be centered on VHDL, Verilog, a little of both, or something else entirely? (...Or is this an eternal, undecidable holy-war question along the lines of ATI/nVidia, AMD/Intel, Coke/Pepsi, etc...?) At this point, I've only seen a little of both languages, so I have no real preference. Any input, especially if you're using one or both in the field, would be very helpful. Thanks, and may all of your K-maps be glitch-free."
Speaking as someone who just got his first Verilog-based design working on a Nexys2 board, I can confidently say that there are two serious mistakes a n00b can make:
1) Thinking of Verilog (or any HDL) as anything like C. Yes, there are semicolons. Yes, you can write a "for" loop, if you want to synthesize a huge mess. That's about it.
2) Thinking of Verilog as a programming language at all. HDL stands for "Hardware description language," and that's what they are.
Verilog is fun stuff, but it's the hardest thing I've ever taught myself. For those who are trying, I've found the Bhasker books on synthesis to be quite useful, Pong Chu's FPGA Prototyping with Verilog Examples to be reasonably useful, and most of the others to be fairly worthless. Too many books focus on simulation at the expense of synthesis practices, IMO.
Also have just received Richard Haskell's new books on basic and advanced Verilog using the Basys and Nexys2 platforms. They look very good at first glance but I haven't yet had a lot of time to spend with either of them.
Having now read through the entirety of the comments on this story, the trend I see is that:
A) students who learned with VHDL then went on to a career with Verilog think the transition was easy and either language is fine, while
B) students who learned with Verilog then went on to a career with VHDL, while rarer, think VHDL is a harder language, and
C) students who were forced to take VHDL when it wasn't in their career plan hated it, because it was so different than a programming language.
Based on that review, I'd say teach your students VHDL. The students that learn it and do well in your course will have the easiest time in the industry, and those that hate it probably won't become good HDL designers regardless.
It doesn't hurt to be nice.
When I got into verilog, there was no standard method to support Silicon Asic libraries in VHDL, so verilog owned the Asic market.
I've done both, currenly VHDL, but found Verilog easier to use, both for design description and for testbenches. Verilog (or at least Cadence-XL) has always had file read/write access, and a linking setup very reminiscent of the way a C compiler works, that and the fact that it offers an "include" mechanism like C makes it very easy to compile and link in various test "programs" into the whole testbench.
I found it very surprising how difficult this is to do in VHDL actually.
Some designers I know glue TCL scripts in to handle testbench functions instead of doing so natively in VHDL..
Bavarian Purity Law of Rice Krispie Squares: Rice Krispies, Marshmallows, Butter, Vanilla.
I've been in the industry as a chip designer since 1995 (board designer for 15 years before that..) I learned Verilog in about 2 days because I knew C thoroughly. My experience applies to someone who is already a designer - which isn't the case here.
I also know that there are some limitations of the original definition of VHDL that make it a pain to use. The strong typing gets in the way of getting the logic described. VHDL natively can't do things like signed arithmetic. That's why you have all those IEEE packages! In other words - the language is extensible - but you pay a price in lack of brevity to describe the hardware you're after.
There are features of 1995 Verilog that also are a curse and a god-send. The assumption that any undefined term is automatically a wire can save you lots of trouble in the creation of the design or bite you in the posterior (where a strongly typed language would save you from yourself.) So Verilog takes on the original K&R attitude of the programmer being smarter than the compiler and knowing what he/she is doing.
No come into the current century and we have System Verilog. System Verilog = Verilog + Vera + the best parts of VHDL (things like generate).
Where VHDL and Verilog were lacking for strong verification methodologies (that in truth were developed years after either language came into being...) System Verilog has been updated to handle this job adequately along with the task of describing the hardware.
The real answer is that you have asked one of those religious war questions - just like VI vs Emacs (Obviously VI is better ;-) Let me give you a URL that you can read about a contest that was held at DAC some years ago - http://www.angelfire.com/in/rajesh52/contest.html
I worked for both Yatin and Larry (two of the conspirators in this story) You be the judge of the Verilog/VHDL war.
I also believe there is a very definite geocentric component to these arguments as has been claimed in earlier posts - In the US Verilog is dominant - while in Europe it's VHDL. I can't speak to other continents. ;-)
In my time as a consultant in the field - I've had two projects out of roughly 20 that were VHDL. Now-a-days these tend to be multi-language affairs where we have both VHDL and Verilog mixed together. Modelsim, and the Cadence offerings handle this pretty transparently (can't speak to the Synopsys tools - haven't used them in better than a decade at this point.)
As another data point - the vast majority of reusable IP that I've seen was done in Verilog. (This may be due to the geographic component - mostly US companies.. ARM being the exception - but everything I see from them is primarily in Verilog... ;-)
Okay - that's lots of data as to what you should do - I would think you should concentrate on teaching about the synthesis subset, proper digital design AND how to write verification environments before they ever even WORRY about FPGAs. What I've seen are a lot of non-designers getting into FPGA design - and they are clueless about things like clock domain crossing and testing the design in simulation BEFORE they go to the FPGA. The old 90/10 rule applies equally here. Do the homework on the design FIRST with simulation before you try to debug every little problem when it's been realized in hardware as an FPGA. I would imagine that students who are trying to become designers are going to suffer the same pitfalls if not shown the RIGHT way to do things.
Hope this gives you some data. In the long run - whether you use Verilog, VHDL or better yet - System Verilog doesn't matter so much as teaching the proper design and verification methodologies!
Have you compiled your kernel today??