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."
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.
You forgot a few:
Linux vs. *BSD
VI vs. EMACS
Gnome vs KDE
etc.
I'm in Computer Science, a somewhat related field, and I've had to take a few hardware courses during my time in school.
I felt like Xilinx Schematic layout was a great first step, because it introduced the circuit theory in a visual way.
I fear the Y2038 bug
First mistake I always find in these courses is to focus on the language, and not on the skills necesary to make full use of them. I would actually focus the course on your existing schematic and know-how, and bring in the languages used later on, preferably both presented alongside such as SystemC. But that know-how will be far more valuable than any single language possibly can be.
Karma Whoring for Fun and Profit.
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.
I am becoming gerund, destroyer of verbs.
Seriously, learn both. The languages aren't that far apart in reality. VHDL is simply a little more verbose. Both can be learned to an extent that you can make sense of most of the designs on OpenCodes.org in a day. (Yes I said a day! At least that is how long it took me.) There's really no good reason to avoid the little bit of work, that will make your life easier in the long run. If you really want to learn to program FPGAs you need to learn to read other people's designs. Many of the things you won't just figure out playing around with FPGAs have been solved by other people who have kindly placed designs under open licenses. However, since you have no idea which design language it will be, it is better to become familiar with both the popular ones. Eventually, you'll inevitably choose one for your own projects, and the only way to adequately assess them is to use both for a while and figure out which one meets your needs and you can tolerate.
I work at a chip company doing ASIC and custom SOC microprocessor stuff. We mostly use verilog here for our stuff. Most of the VHDL I see comes from customers, which often gets blended into our verilog platforms. All our RTL IP cores are verilog that I know of, at least that I've used/seen, and our integration work to make platforms out of all the IP pieces is verilog. What we synthesize to gates is also a verilog gates netlist result that goes to place/route into silicon.
In college the class I took that involved this sort of thing was in VHDL, and I hated that. had me really nto wanting to do this kind of work, I was really happy when I was exposed to verilog and I didn't hate it, and I've been a chip guy for over 10 years now.
But as I understand, VHDL is far more popular in some locations, and verilog in others, so jobs in other locales may be completely opposite to my work environment. It would probably be nice to show some of each to be a little familiar with both such as comparing/contrasting = to = and == to ===, but focus on one or the other for people to really get experience fitting pieces together and learning the general stuff about RTL design, etc. that are not as dependent on what language you use.
I've worked at several top chip companies in Silicon Valley, in graphics and telecom industries, and they're 100% Verilog. I also suggest learning System Verilog as well, especially for testbench development.
Learn both, but start with Verilog. Many of VHDL's features are a bit academic, but once you know what is relevant from Verilog it makes it easier to find the "usable subset" of VHDL that's actually good for FPGA design.
System Verilog is the new kid on the block - they ironed out some of Verilog's oddities and added in some of VHDL's very useful features.
Altera already offer System Verilog support, Xilinx support is apparently on the way.
Verilog is a lot easier to learn in general, but VHDL has a great feature ("Records") which are akin to "structures" in C that Verilog doesn't offer.
System Verilog does, which is why it's on my list to learn next.
One other poster made a good point - learn logic design first, then make the language describe the logic for you.
If you don't have a clear idea in your mind how to map out a design in gates and flipflops, (block diagram on a whiteboard is always good) then you should not start coding in an HDL..
Both languages can lead you down the path of unsynthesizable nonsense that seems to simulate ok..
Bavarian Purity Law of Rice Krispie Squares: Rice Krispies, Marshmallows, Butter, Vanilla.
My university has been very successful using VHDL in our intro embedded programs. Check out this book on VHDL programming: http://www.amazon.com/VHDL-Digital-Design-Frank-Vahid/dp/0470052635
I'd say I'm right about in the position you're talking about. I'm getting close to finishing my degree and a lot of the work I've done has been with FPGA's. My introductory class to the area used verilog (although no procedural, code for flip flops was given to us to instantiate). The next course we used VHDL and have used VHDL extensively since then. Both VHDL and Verilog have there strength and weaknesses but overall, for anything an undergrad will be doing, there are no significant difference in functionality. The only real difference I could see coming into play here is which would be easier to pickup. Verilog has a syntax similar to C. Operators are the same, variable declarations are similar. This is in stark opposition to VDHL that has a syntax that is distinct from anything other language I've ever seen. Then VHDL really contains 2 languages in itself, concurrent and procedural, which for whatever reason have completely different syntax. I still find myself on occasion referencing the syntax for some parts of procedural. So actually learning the syntax, I give it to Verilog. It is familiar looking (I'm assuming everyone taking said class will at least have some background in C) and easy to catch onto. The real kicker for me to advise VHDL over Verilog is that VHDL is strongly typed where Verilog isn't. Being a beginning class, you can expect the students to make a lot of mistakes. VHDL will complain at compile time and just crash throwing out a million error messages. Verilog will happily try to run it if at all possible meaning you may not find the bug until you've searched through the simulation results which can take a while. This is something that can get prevented(ie. 4 bit addition being stored to a 3 bit variable or comparing an unsigned value to a negative) by VHDL strongly typed nature. At least for me, and probably most students, it's nicer to get the complaint when I compile it than it is to go search for an error in the output. Lastly, this I'm not as familiar with, but I understand that Verilog is more heavily used in industry whereas most government contracted stuff is done in VHDL. I don't know if this factors into your decision or not. So my suggestion, if the students seem competent and can avoid simple mistakes, either language will do but Verilog might be slightly quicker to learn. But if it seems that they will be error prone, VHDL is probably the better choice.
In many ways schematic capture is an easier first step. You can hold off on Verilog or VHDL until you have made every flavor of flip-flop yourself. If you can get logic that has a few to several dozen gates to work first, then you can consider an HDL. And it doesn't really matter too much. There are pros and cons to each, and different industries prefer different languages. Actually different regions of the world prefer different languages too. Verilog is extremely popular in Silicon Valley, but on the East Coast you will find a lot more people using VHDL.
Many who prefer one over another do so because of features for doing verification. Until you know what verification is all about you probably won't be able to make an informed decision.
This fact makes it easy for most people: Icarus Verilog is open source, free and multi-platform. And useful for doing verification work, and also is capable of generating netlists to use with your favorite Xilinx or Altera parts. I'm not saying it's amazing or anything, but it does have some advantages for a hobbyist doing small projects.
“Common sense is not so common.” — Voltaire
Having worked in Silicon Valley and in Europe I have lived through some great battles of Verilog vs VHDL. Even had an engineer reminding me just lack week why VHDL is better. The reason he though it better was because it would not have allowed a port size mismatch that lead to some strange waveforms when the Logic Analyzer was configured the way he imagined it should be. None the less, Verilog is used for more ASIC designs then VHDL. (Simply ask the tool vendors Synopsys, Cadence, Mentor.)
For me Verilog is closer to describing HW and allows an engineer to do what they want. It is like a sports-bike. It will get you there very fast and you can cut a lot of corners. But, watch out or you will be in a ditch pretty quick.
For students, it is most important that they learn HW design before learning Verilog or VHDL. They need to understand the parallel nature of HW, and should be familiar with state machines and Karnaugh map reductions. In general they should not be writing shifters with for loops. Both languages allow you to describe HW that looks OK in simulation and has a whole host of problems after synthesis. I would teach Verilog because the language will not force good design and the students will be forced to learn when their FPGAs have problems. VHDL, on the other hand, will provided training wheels that allows the user to not truly understand what they are doing and still pass the class.
There were very good reasons why people used VHDL in the past. Because VHDL was an open language before Verilog, the cost of VHDL tools was historically lower than Verilog tools. Since this cost was much more important to FPGA designers, VHDL tended to dominate the FPGA market.
On ASIC side, the first mainstream commercial synthesis tool was Synopsys and Synopsys chose to support Verilog before supporting VHDL. Amongst all the other NRE costs in designing an ASIC, the added cost of using Verilog tools (instead of VHDL) was not really significant. Also, tools to support large designs advanced initially as Verilog tools.
Fast forward few years and Verilog is now open, the cost differential has now disappeared. However, VHDL had a lot of features related to design validation that were not in Verilog. In VHDL you can read and write files. Such things as configurations are supported, etc.. This type of capability makes it easier to write a testbench in VHDL, while on the Verilog side, additional tools and languages are commonly used.
Fast forwards a few more years to today and now we have System Verilog. This gives Verilog the capabilities that it lacked in comparison to VHDL and probably more. The price of VHDL tools is the same as Verilog tools.
Summary: it's clear that the future does not belong to VHDL. It looks like System Verilog is the future, although there are other contenders. So, if the choice is between VHDL and Verilog -- pick Verilog.
The real "Libtards" are the Libertarians!
As other people have pointed out, the important thing is that neither Verilog or VHDL are sequential programming languages... They are hardware description languages, or could be thought of as parallel programming languages or simulation languages. In any case, students will make the biggest mistakes by: 1. Thinking that it's just like C/C++/Java/whatever, and 2.Using features of either language (which are both quite powerful), but that are unsynthesizeable.
Thus, an important part of any course on HDL should have a heavy focus on synthesizeable code, with many iterations of seeing not just the "right" way to do things, but why that is the right way and the alternatives wouldn't produce the same (presumably good) hardware as the alternative ways that look or seem similar.
There are many other languages to consider as well that may or may not end up being used widely in industry.. a sampling is...
SystemC
HandelC
BluSpec
Plus, there are many C-to-Verilog, C-to-VHDL or C-to-HW compilers out there that try to jump from sequential code with pragmas etc. to the HW....
In general, I would suggest thinking of this not as a language course, but as a hardware design course where the tools used happen to include a new language (for the students). It would be easy to concentrate on language syntax and end up with students that know syntax, but not how to make good HW descriptions....
I work at a mixed signal IC company that is, on the digital side, principally a Verilog shop. We do have one or two projects that use VHDL, and maybe even one or two that use both. From a practical applicability point of view, Verilog is a bit more popular as far as I know, but this should not be taken to imply that you will do your students a disservice teaching them VHDL. When we interview digital designers, we don't ask them "do you know Verilog?" we ask them "do you know digital design?" The language is far far less important than the underlying concepts.
The biggest mistake you can make is concentrating on the language and expecting the programming skills will apply to digital design just because the syntax of Verilog looks like the syntax of C (or VHDL looks like Pascal, if you squint a lot). First, learn how to do digital design, then learn how to describe those designs in an HDL. Things might go slightly faster if you are familiar with the syntactic structures (i.e., C coders will feel more comfortable using Verilog), but trying to take the "do-while--if-then-else--for" mentality of a procedural coder and trying to jam it into an FPGA is going to be a painful road to failure.
It's time for a bad analogy! "Hey guys, I have a bunch of novelists whom I want to teach to write medical textbooks. Should I teach them to do it in English, or Spanish?" The answer is "whichever they're more familiar with already... but first teach them medicine."
-=rsw
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.
We were introduced to VHDL in our University's Digital Circuits course.
Most of the above commenter's have mentioned that Verilog is C like, I personally have never used or programmed in Verilog so I can't comment on that.
I did however like VHDL very much, particularly because it was *different* from C, I'm kinda growing tired of C like languages and VHDL was a breath of fresh air. It made FPGA's and the entire course in general a whole lot of fun.
It's strong typed nature was a bit cumbersome at first especially with converting std_logic to std_logic vectors and such because we weren't really shown how to do this or given a syntax/library reference like MSDN or Java's Documentation site.
So I'd say make a good introduction to Entities, Ports and Architectures, explain Process, Signal and Constant statements very well, also particularly highlight the strong typed nature of VHDL.
I think most of your students (such as myself) will not have done any programming in a true strongly typed language before, so this will be bit of a shock, and getting those conversions will be frustrating. (I have been there, Googling really does not help all that much)
I hope your students get as much fun out of that course as I did.
Cheers,
filereaper.
VHDL and Verilog each have their strengths, which is why neither has been able to supplant the other. Perhaps in the long run System Verilog will change this (bringing much of the power of VHDL to the Verilog world), but that day hasn't arrived yet.
Verilog code tends to be very concise, with the language making some implicit conversions and assumptions that turn out to be correct most of the time.
VHDL is bigger, bulkier and more rigid. The rigidity can be annoying, but it also is good at catching errors. The language has features that allow for very elaborate testbench construction, and some powerful means for abstraction (the generate statement, multiple architectures for an entity, etc). But this power comes at a cost. The spec for the language is several times larger than for VHDL. At one point I had a Verilog quick reference that fit nicely on a single page. My equivalent quick reference for VHDL covered four pages.
I've gone through the "choose an HDL" process twice, and both times selected VHDL. But that was within the context of at least half the team already being fluent in VHDL, and working on a large enough (and long lived enough) codebase that we could take advantage of some of VHDL's power. I wish VHDL wasn't so cumbersome and verbose, but it was still a win overall.
You are in a very different situation. I'm assuming you have minimal experience with either language, and it will be new to your students as well. You're going to have plenty of other things to be worrying about (digital design, synthesis, debugging, etc). I think Verilog is a better choice for your situation. It's going to do everything you need, and not really get in your way.
Also, don't worry about which tool is more popular in industry. Tools change many times over a career. University classes should be about providing good theory and foundation, so pick whatever tool enables you teach those concepts most effectively.
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
How is this info relevant in 2009 ? I've been working with Xilinx in the last 9 years and can attest that their software has a decent quality. By "decent" I mean no better or worse that its competitor Altera. There are occasional bugs which are quickly fixed or tech support offers a work-around.
Thanks
Visit http://outputlogic.com/ : tools that improve productivity
Finally a topic I care enough to go register in order to put in my opinion... Let's see how bad I get slammed :)
I work in FPGA's and have done a couple of relatively small projects in them. I have exclusively used VHDL. But after I taught myself VHDL, reading Verilog is pretty easy.
It is a Coke / Pepsi thing because you are asking for a "better" decision. Most jobs can be done by either language. VHDL is preferred in some circles, especially military / DOD / Aerospace (where I work).
Verilog has a shallower learning curve for those used to sequential programming languages like C.
VHDL is more powerful if you can think in terms of the underlying digital hardware (propagation delays, clock hold times, clock domains, etc).
And not to be too pedantic, but VHDL is NOT a programming language. A programming language is something that ultimately is translated into a series of instructions for a processor. VHDL is a hardware description language. You are actually describing a piece of hardware that will be implemented as a set of gates on a piece of silicon. VHDL code will never result in instructions and will never be "ran". It will be implemented in hardware and will respond to inputs and produce outputs per your design.
My answer, it depends on your goal. If you want to produce a more rounded CS major capable of understanding this aspect of technology, focus on teaching Verilog with some VHDL examples to highlight the differences. If you want someone that could go produce useful work after graduation, focus on VHDL.
I know I will probably be unpopular because Verilog is more prevalent among the "traditional" programmers because it is an easier leap from C.
Now having said all that... System Verilog has a LOT going for it, and when the tools catch up to the Language Reference Manual, then it could be an extremely powerful design language. This presentation from DATE 2004 shows why. http://www.systemverilog.org/techpapers/date04_systemverilog.pdf
"VHDL was created by hardware engineers who know nothing about programming languages. Verilog was created by computer scientists who know nothing about hardware."
Ummm, no.
Oops, I got the quote backwards (duh), you're right (obviously).
I've found that I can substantially reduce VHDL development time using Xilinx System Generator and its toolbox for Matlab's Simulink . Writing VHDL graphically makes understanding and testing substantially easier (for me, at least).
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).
It's been about ten years since my TAs and I taught the lab section of the advanced digital logic design at my university. I agree that, generally speaking, VHDL is a better teaching language than Verilog. Part of the reason is that Verilog, being much like C, is inherently procedural. You don't want to think procedurally with digital logic except for the specific case of state machine design, and even then you have to take into account concurrency. It is this fundamental aspect of concurrency in HDLs that is key to being able to design effectively. I can define twenty clocks going into counters, just like I can wear twenty watches on my arm and have them all tell time independently and/or at different speeds. You can't really do that with procedural languages unless you're talking about thread scheduling, and then this becomes a thread scheduling exercise when you have multiple threads. Even then, you will never be able to get the speed of digital logic because you have instruction fetch, instruction decode, etc. that introduce latency that cannot be reduced even in a multi-core CPU. Not thinking procedurally will help, and the strong typing of VHDL over Verilog will help greatly in my opinion. Those Karnaugh maps you talk about are fine to learn, but HDLs use case statements in VHDL that make state machine design trivial especially when you have >8 states.
Beyond HDLs, however, are FPGAs and ASICs (and I've designed using both). Putting the differences between FPGA and ASIC aside, FPGA has some very specific ties to the vendor because of the way the FPGA is architected. Assignment of I/O, synthesis, and most of all timing constraints for guiding the "map place and route" tools for FPGAs are something you won't learn from VHDL alone (e.g. clock domain frequencies, max/min delays, input/output delays, false/multicycle paths, setup and hold times or worst-case timing paths in the design). These are essential to digital design, but not part of the HDL at all (see Synopsys SDC format for more info). In fact, shell scripts, sed/awk, Perl, TCL, Scheme and Python are also essential to know because they glue the various different tools together through scripting, processing of text files, tailing log files, and batching can be critical to being efficient. So is being thorough in understanding log file warnings and errors, timing reports. Electronic Design Automation or EDA tools also have their own idiosyncrasies, and you'll need to develop a stable "reference front-end and back-end design flow" if you haven't already. Do you use an Altera or Xilinx reference board, or an add-on PCI-based FPGA card? And how do you analyze what's coming and going at the interface? All of these questions need to be answered before you really get going on FPGAs. ASICs have an order of magnitude more complications for reasons I won't even discuss, but it just gets harder. So those state machines that you created without K maps will have synthesis pragmas that direct the compiler to create the appropriate state machine (e.g. One-hot for performance, Gray code for lower power, etc.).
Finally, there's the work world. As other posters have mentioned, North America is primarily focused on Verilog while the rest of the world is VHDL. Most synthesizable IP cores for various functions come as Verilog. So, the truth is, you should know both major HDLs, but you would be better off being proficient in Verilog in the real world for the simple reason that it is the present and future (or at least its successors, such as System Verilog, are the future) are for many reasons. Also, in the work world, it's critical to know the major EDA vendor software and to put it on your resume (i.e. Mentor Graphics, Synplicity (for FPGA), Synopsys, in roughly that order, and Cadence and Magma for ASIC) as well as all those scripting and other languages like Perl and TCL that I mentioned. Don't completely ignore VHDL, however.
As an ironic point, there are SystemC compilers for hardware that are becoming more and m
You're right that Verilog has those constructs, but they're strictly used for modeling. You either won't make synthesizable code out of them, or if it handles them it's done in an implicit way that you absolutely have to know what the implications are. Again, HDLs are not programming languages in the get-to-the-chip sense, they're concurrent systems description languages. Even more reason to leave Verilog alone at the outset and learn with VHDL.
Strongly disagree here.
You can do about 99% of what most HDL folks do for FPGAs using Verilog and VHDL. Verilog does it in a more familiar syntax. VHDL requires considerably more pomp and fluff to accomplish the same goals.
It's true that VHDL *may* be more appropriate for bigger, careful projects. But students need to learn principles without tools and other things getting in the way.
Teach principles of HDL with the least roadblocks, then allow more in-depth study to accomplish more. The relatively few students that go on to use what they learn in a class in depth will learn as necessary. If you can get through to ALL of the students using simple tools and languages, then you can teach the fundamentals of HDL and that will stick with them for a long time to come.
Why would you say something as silly as that spice netlist format is not a programming language?
Nonsense. Teaching the tool is the job of a vocational program. The theory of HDL will long out-last any particular errors or syntax that come about.
Except in this case the tool is intricately related to the "theory of HDL". This isn't some "sorry, you used \r\n instead of \n" issue. VHDL compile errors are real design issues. Basic issues that every designer needs to understand.
Example:
integer count;
bit [8:0] bus;
always @(posedge clk, negedge reset) begin
if(reset == 0) begin
count = 0;
end else begin
count = count + 1;
end
end
assign bus = count;
This is all legal in Verilog. Its equivalent VHDL would throw a huge fit. Does the student who uses Verilog for this understand how it will be translated? Design Compiler will do the following things "behind the student's back" with a list of warnings inside the log that most undergrads won't bother looking at:
1. It will assign "bus" to the first 8 bits of count. This may or may not be the desired behavior.
2. It will treat count as a signed integer, it's probable that it is meant to be an unsigned counter.
3. It will optimize by encoding the counter in something other than BCD. The ambiguities of how the bits of "count" are assigned to "bus" with the encoding scheme of choice are non-obvious.
VHDL makes you explicitly describe all of these things. It may seem a "pain in the ass" but these concepts are ones that any designer should understand *before* they commit something to silicon (or SRAM in the case of Xilinx).
After you understand all of this, moving to Verilog will save you time (as long as you're careful) by letting the compiler do more of the manual translations for you.