VHDL or Verilog For Learning FPGAs? 301
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."
Where are you located? (Score:5, Interesting)
Personally, I would say that Verilog is more C-like: weakly typed, compact, efficient notation, whereas VHDL is much more Ada-like: strongly typed, often verbose, but can catch errors that the other one can't.
In industry, as far as I can tell, Verilog seems to be more used in North America and VHDL in Europe, so that might affect what you care about, too.
Personally, I prefer Verilog.
Schmatic layout? (Score:3, Interesting)
I felt like Xilinx Schematic layout was a great first step, because it introduced the circuit theory in a visual way.
VHDL of course (Score:5, Interesting)
Let's put it this way. I once implemented a subset of TCL in pure VHDL to implement feature rich scripting for simulation data. That can't be done in Verilog without dropping out to C.
Re:Where are you located? (Score:5, Interesting)
I agree with the above post, though I personally prefer VHDL. That might however have something to do with me having designed ASIC/FPGAs for about 11 years now using VHDL though. :) Both are very powerful languages these days, and I see no problem in teaching a course using both languages, showing how to create the same hardware using different language constructs.
Re:Where are you located? (Score:3, Interesting)
I agree about the industry part, although I find it ironic since VHDL arose from DARPA funded work whereas Verilog is a proprietary innovation turned international standard. At school I learned VHDL though. This wasn't a problem when it came time to use Verilog at work.
My advice: cut against trend. If you're a North American school, use VHDL. If you're in Europe, use Verilog. It may be the only chance for your students to taste the other side.
The insanity of VHDL is attaching two things that you know are 'just wires'. In my experience you spend quite a lot of time writing type-conversion adapters.
Re:Where are you located? (Score:3, Interesting)
Verilog is more popular in the ASIC design industry, for certain. But I work at a large test instrument manufacturer whose products are based heavily on FGPA design, and we are exclusively a VHDL shop.
It is my understanding that Verilog is moving towards stricter type definitions, so that it can get some of the benefits that entails. If you, the submitter, are looking to learn/teach a language least likely to change in the near term, go with VHDL.
That said, a good engineer should be able to sit down with the unfamiliar language and read it, and after a week training course write in it with professional quality. So whichever you teach, your good students will do fine in their careers.
System Verilog (Score:2, Interesting)
If your goal is to prevent the students from ever completing their project and running on real hardware, then pick VHDL. Its ADA-like compiler will reject every possible attempt at coding until you master the language.
At least with Verilog you'll compile some gates, which may or may not work functionally, but at least you'll have fun discovering what your code does in hardware.
I was part of the IEEE committee which standardized the VHDL subset for synthesis (a fiasco, but that's another story).
10 years ago, the debate between Verilog and VHDL was that the US was using Verilog and academia and Europe were using VHDL. That's over: pretty much everyone switched to some form of SystemVerilog.
In the end, what really matters is that students can go back and forth between any given language construct (blocking assignment, missing assignment, for loop, etc.) and its hardware equivalent (flip-fop, latch, mux, etc.).
Very few people are good at this. The ones that do make $150,000+ in Silicon Valley. So it is definitely a good career path.
Test Benches (Score:2, Interesting)
I strongly disagree with the idea that these aren't programming languages and that all you need to know about is the synthesizable subset of each language.
I've worked for several years using VHDL for ASIC/FPGA work. Invariably, I spent 2-3 times as long working on the simulation / test-bench as I did on the VHDL that was actually synthesized into the product. There are a lot of very interesting language features that you can exploit to make the testing more flexible and easy. If you tried to make a simulation test-bench out of the synthesizable subset, you're being a lot less efficient than you could be.
Also, I have a strong preference for VHDL's strong typing and pseudo-object oriented features over the wild-west down-in-the-bits Verilog style. I think it's easier to manage complexity and reuse code in VHDL.
That said, Verilog is definitely more popular in the US, which is important to consider if you're looking for marketable skills. If, on the other hand, you find yourself in a position to choose the language once you already have a job, I'd strongly recommend VHDL
Re:System Verilog (Score:5, Interesting)
I disagree with the statement that everybody has switched to System Verilog. I've worked with a few companies introducing it, and System Verilog is exactly the reason I want to go back to working with VHDL. It's horrible.
My take on it it is that a load of C++ engineers looked at Verilog and thought "What this needs is object orientation!" completely ignoring the fact that hardware description languages are OO by nature. After all, what is a module if not a method of encapsulating design leaving just a public interface.
The result is a horrible mess of a bi-polar language that can't decide if it's a software language or a hardware one, and the two sides don't really want to talk to each other. Add to that the fact that all of the design patterns that are being used with it are software patterns that don't map well to hardware, that most hardware engineers don't know, and you just get a big steaming pile when you try to introduce it to a company.
The EDA vendors love it because it's giving them a new set of tick boxes they can sell their wares on, but I've yet to see it do anything that I couldn't do in straight verilog / VHDL + a little PLI/FLI, and I've been working as a system verilog application engineer for one of the EDA companies. ...oh and it's really slow (as in orders of magnitude).
Consider Xilinx System Generator (Score:2, Interesting)
It has hand-coded VHDL equivalents for each Simulink function. Generate testbenches, hardware in the loop, etc. You can merge it directly with your own code by writing a simple high level wrapper. It interfaces easily with Chipscope as well (generates files to label each of your inputs).
Re:Where are you located? (Score:3, Interesting)
Verilog is C-like in that it won't lift much of a finger to keep you from shooting yourself in the foot, and it leaves plenty of ammo lying around. With VHDL the language forces you to specify things much more clearly (and verbosely) up-front. If you're going to compare Verilog to C, then you can compare VHDL to Pascal and its ilk. (Or Ada, as someone else said.) Far from a perfect analogy, but also far from incorrect.
I've used both. I first tried learning Verilog by using it for a few months. Then I learned VHDL by using, producing a fairly good-sized functional macro for an ASIC. Some years later I took a Verilog course. It struck me that on one of my class projects, I got caught by a typo, misspelling a variable name on one particular use of a signal. Verilog implicitely declared the variable for me, and I had an open circuit to debug. VHDL would have stopped with a compile error.
But then again, decades ago I wrote fairly extensively in Modula-2. That included interrupt service routines and binary readers for legacy data. So I have a tolerance and preference for the more verbose, tight-laced languages.
Not in the context of FPGA/HDL synthesis it's not (Score:3, Interesting)
Verilog but don't use Xilinx ISE⦠(Score:1, Interesting)
This post is remarkably well timed: I'm currently procrastinating over doing an assignment in Verilog for an undergrad course in FPGAs.
I'd definitely pick Verilog. The main problem will be what you choose for compiling. If you use ISE 9.2 (the immediately obvious choice for a Spartan board), make sure you check your brake lines every time you get in the carâ"your students will hate you.
I think Verilog offers the best combination of usability and actually learning about hardware.
Re:Where are you located? (Score:3, Interesting)
That's just mixing semantics. The reality is, from a computer architect's world, there is a clear separation between "programs" and "logic". Programs have the features:
1. They are made up of a finite set of instructions.
2. They can be arbitrarily as big depending on available storage.
3. They control functionality.
HDL's don't create this without some help. You can take an HDL description of hardware and emulate it in software, yes. And you'd have a program. But at the end of the day, synthesis turns it into gates; a mapping of logic cells and wires. That's not a program. FPGA tools will turn that mapping of gates into mappings of its native cells. In Xilinx -- and only Xilinx -- FPGA's, this turns into a bitstream of SRAM bits that might conceivable be called a program. In all other FPGA architectures, it's actually a description of which fuses (or anti-fuses) to burn.