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.
Once you understand the concepts, switching to the other is relatively easy.
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.
Very Hard Dumb Language
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
It's much quicker to get things done in Verilog than VHDL. You need to know Verilog if you want to deal with post-synthesis/layout netlists anyway.
Also, SystemVerilog is where the future is, so much better to start with Verilog than VHDL.
I hold a Bachelor of Science in Electronics Engineering and did quite a few projects on Xilinx FPGAs the last couple of which I did in VHDL. Love the language. Easy understandable and using the Xilinx Developer Software ( incl. Schematic tools ) development was a breeze. :-D Also did VHDL in the industry.
Never buy Sony CDs - they will open up your computer to anyone..
My University used VHDL for our FPGA class because that was what the professor was familiar with. However, I found that around 75% of the reference material that I was able to find on the internet was written in Verilog. It would have been much easier if I had been writing verilog.
Both languages are old and the tools you have to deal with are incredibly complicated. I really don't think it will matter which you pick (I personally see Verilog used more in universities, but that doesn't make it the right choice). What you do need to worry about is coding style. Most students learning an HDL for the first time will come in with programming experience. They're going to try to use programming constructs and loops that, while appropriate for normal code will not represent synthesizable hardware. With that in mind you need to pound style rules into their heads. Since one of primary functions of each language is simulation (as opposed to synthesis) using legal code may lead you into trouble. Get around this by enforcing strict style rules. Example set of Verilog rules: http://www.eecs.umich.edu/eecs/courses/eecs470/tools/verilog_guidelines.pdf [eecs.umich.edu copied from C. E. Cummings, âNonblocking Assignments in Verilog Synthesis, Coding Styles That Kill,â SNUG 2000. (http://www.sunburst-design.com/papers/CummingsSNUG2000SJ NBA.pdf)) Every time you code remind yourself "I am writing hardware".
Both are like using assembler. Useful for educational purposes, but someone using a higher-level language will have a productivy advantage. Look at CDL Cyclicity for a higher-level example (on source forge). It compiles down to verilog.
Who's teaching the course, you? Have a look at them and see if you have a strong preference. Most people do one way or the other. I like Verilog and hate VHDL. I think the instructor should teach what he's more comfortable himself, so you're all more confident that he's teaching it correctly and not tossing out things that are confusing and may be somehow inaccurate in that language he's not as good with. I could help someone understand Verilog, but I would be a horrible teacher/mentor/tutor in VHDL trying to read and understand my answers to questions from the same (and/or other) books the students have. Other people are likely the reverse. Which way does this intructor for your course go? It'd be nice to find that out before you choose the wrong language for him.
Of course a superb instructor would be fluent in both, and more, but it'd be nice to avoid focusing on a good but fluent in only one teacher's weaker language.
I have taught both for use with Altera FPGAs. IMHO VHDL is better for teaching our students. The main problem we have here is that most of the students have already had lots of experience programming C++, java, pascal... One would think this is an advantage, however most of the students then program hardware like they would a software program. This just does not work. VHDL, is a strong typed language, and there are well defined sequential and current statements that fit well with hardware. Its not perfect, but I think it allows the students to differentiate a software and hardware program better. Lastly, from my experience, if you know one hardware language, it is not too difficult to pick up the other.
At the university I teach at (Michigan Tech), we have selected Verilog design for our Altera FPGAs, and have been using it for 5+ years. I used Verilog in private industry before I started teaching and it *seemed* to be more common at that time. When I did some time at IBM back around 1998, they were using VHDL. One of the companies that hires a lot of our grads uses VHDL, and I keep having to tell students, "Look, if you know Verilog, all you need to get a handle on is the syntax of VHDL. Tell them that!"
Knowing both, I find students struggle enough with the concepts of logic design and simulation when they have a familiar kind of syntax (the C-based syntax of Verilog), let alone adding the complexity of VHDL's strange ADA-based syntax. I suggest Verilog.
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.
FPGAs, you say? How about prototyping in Haskell? Here is a link to some videos describing the process.
VHDL has a lot harder learning curve than Verilog, so it would be better to learn VHDL in a classroom environment. Once you learn VHDL, Verilog is cake to learn. I can say this from experience.
I've heard going from Verilog to VHDL is a painful process. Either way you learn them though, make sure you know them both.
I know it's a little "old school," but have you considered using Rocky's Boots?"
It's been a few years since I used it, but I thought it was a great tool at the time.
As a computer Science major, I only had one class involving this sort of thing, and it used VHDL. We all hated VHDL, and though I've never even used Verilog, and have only seen if briefly, I've heard others say its much better to deal with the VHDL. But then again this is all from memories I have from 3 years ago, and like I said, I've never used Verilog, so take this with a grain of salt.
Patent: from Latin patere, to be open
I assume the intent is to teach about how to get your logic into an FPGA, what the internal structures look like, how synthesis maps from language into implementation, etc.
Any good designer has a mental model of what logic is going to get synthesized by a particular snippet of code, I find verilog gets in the way of expressing that model a lot less than VHDL, so I would say verilog is a better choice, in that you can get to the subject you want to teach much faster. Way less time explaining all the VHDL verbosity just to get to a working example.
-- All that's left of me, is slight insanity, whats on the right, I don't know. -- Bob Mould
Both. I'm an EE that has worked a little with both and frankly the subtle differences and blatant ones as well need to be covered to fully understand the concept of what an FPGA does. Yes certain markets have preferences, but it would be like teaching a computer scientist only one system. You can emphasize one, but dont screw the other over and forget it entirely. Plus the implementation of FPGA's is not simply a focus of the language. The use and design of FPGA based systems is more complicated than its language. You can make hardware do alot with different software ways. Not gonna lie, this is another holy war and everyone has their opinion. As a student the objective is to learn as much as possible and not simply "develop a preference" and teaching both puts the decision on the student as to which they prefer.
Every camp has their proponents, so it doesn't matter. Just pick one, both work equally well.
I personally use VHDL right now, but at some other company, it was Verilog. You probably don't have time to mess with both if the whole point is to do FPGA, not learn a hardware language.
I did a similar course about a year ago and we used Handel-C. Assuming your students have coded in C before they do not have to worry about picking up the syntax, but rather they can focus on the parallel aspects of embedded programming like parallel execution and channels. I found it adhered to ANSI C reasonably well and actually improved my knowledge of the hidden depths on data representation in C. It "feels" like using C but with a few Occam-inspired macros to help create parallel code. The similarity between C and Handel-C also helps to bring home concepts like recursion is not possible in hardware, but iteration is. Also the documentation is thorough and clear. The reason we were given for using Handel-C over VHDL was the difference in overhead of learning a new syntax and of lower-level programming. I guess the downside is that the resulting circuits are likely to be much less efficient than in VHDL.
As an undergraduate we studied both VHDL and verilog in our course. Actually students need to know both as there are options of writing VHDL code inside verilog code these days. Personally I prefer both.
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
I'll go out on a limb here: SystemVerilog . It is the obvious future of HDL for both RTL and verification
I'm seeing a lot of people complaining about VHDL and praising verilog, but I've used both and I'd say that the difficulties encountered with one will be seen with both. A lot of these complaints are just people who did some programming in VHDL and hated it. Using an HDL is not like using a normal programming language, and getting over that hurdle is what will be difficult for most people.
As far as what to teach in the class, identify what hardware you are going to use first, and then look at the tutorials supplied by the company supplying the boards. Most companies (Xilinx, Altera, to name a few) have tutorials they supply to use on their boards, that you can use as a first-step in designing coursework. I would make the language decision after checking what is supplied by the company.
-T
No really. There are tools for us old timers that let you design at the gate level, and then will create the code for you.
---- Booth was a patriot ----
I would argue that it also depends on what industry you eventually see the students going into. While a lot of people may like verilog better (myself included), almost ALL defense/military systems are written in VHDL. Their claim is that VHDL forces coders to be more careful and prevents some errors commonly made in Verilog from appearing.
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!
we have been using Simulink with DSP builder (from Altera) and we are very happy with this framework. We've used both Verilog and VHDL and we fell that Simulink is the fastest way to get a project up and running on a FPGA. Only problem, it is not cheap...
A picture is worth a thousand words, and a schematic is worth 1,000 lines of VHDL Disclaimer:
I have been using Xilinx since the 1800 (approx 1980).
Sent from my ASR33 using ASCII
If you understand how to design hardware, either will get the job done. If you don't, both will give you crap.
To be honest for a college level program I don't think it matters. I learned VHDL in school, but only use Verilog at work. Hasn't much impeded me. There's a mild learning curve but if you know one you know the concepts necessary to easily learn the other.
...it was game over. I was a staunch believer in VHDL and its many features (generics, records, operator overloading, strong type checking). But once Verilog implemented proper signed arithmetic which didn't require tedious manual sign extension in the code, then I never looked back. SystemVerilog continues to push Verilog forward. gwait (179005) had the right idea - start with Verilog, and if you ever need to work with VHDL, you will have a much better idea of what aspects of the VHDL language you do and don't need to learn.
Personally we usually look for VHDL programmers instead of verilog - I would recommend focusing primarily on VHDL, touch on Verilog AND maybe expose the students to LabVIEW for FPGA's, or possibly Annapolis Micro's Corefire software just to show them that there are other approaches besides VHDL and Verilog
Hi,
Another possible solution is to use automated translation between C to VHDL or Verilog. The website http://www.c-to-verilog.com is an open source project which gives you a compiler and an on-line service for compiling C to Verilog.
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....
When you can use the open source http://www.c-to-verilog.com. Its much better from my experience.
Again, Open source gives a better solution.
I've only ever used VHDL, but it is fairly clean and easy to get started with.
I suppose I should have given Verilog more of a chance, but I just ran away screaming whenever I opened up a *.v file.
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.
Verilog, I've had to program FPGA's and CPLD's and the one thing I can say for sure is VHDL is the worst programming lanugange of all time. It's syntax is horrible, it's keywords are non sense, it's declerations are crap, all in all it's horrible.
Vhdl solves 0 problems with helping a student learn hardware design. From a personal note I don't think anyone should use FPGA's / CPLD's. They don't solve a single problem that can't be done in pure software. Future more what use is it to say make a Train program on a FPGA / CPLD. There is real use for these hardware device.
My prof made it sound like they were the most important devices in the world and I have to disagree with him completely. I would understand 5 - 10 years ago when we simply didn't have the hardware preformance we have now, then a FPGA / CPLD could be useful.
Well VHDL might have a ton of existing libs for it and it might be reconized widely, it's still a horrible and hidious method of hardware design period. We had to do many labs this year using it and really there was no time saved, NONE, and from what we were taught it would make the job easiler!
After spending 4 months with VHDL and then 1 week with Verilog, there's no completion. Verilog is a much much better method of programming FPGA's / CPLD's. Hands down it wins, it's like asking which is better for programming a airport system , Hand Assembling the software using ATT&T syntax in Windows Debug (VHDL) or using C (Verilog). All the labs the entire class did were preformed 1000x faster in Verilog with a much higher level of understanding.
If you have to pick, it's not a question just and answer it's Verilog all the way. VHDL has to retire, it's of no use, it's horrible to work with, it's horrible to use and forget trying to understand it to a decent level. Verilog is very nice to work with and it omits many of the down falls of VHDL.
I would also like to add that doing FPGA / CPLD design is also becoming rather pointless, with the advances in modern computer programming languages and compiler, it's no longer a case of not having a fast software solution. The hardware and the software are no longer seperated by such a huge amount, well there might be a slight and I mean maybe 1 - 5% increase in preformance using a FPGA / CPLD I don't think that becomes enough of a reason for using them anymore. At least not in college and university programs, doing labs where you have to program a game like Tetris or Space Invaders, what does that teach you. What it does is waste hours and hours of dealing with problems and bugs and crappy syntax do get something that doesn't satify any need.
All in all I think the FPGA and the CPLD,except in special cases, have served there purpose and are no longer a good solution to computer and electronic design. Unless someone can make a hardware desciption language that can actually make sense and flow, the FPGA and CPLD's are done.
Thanks
Murdoch
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.
VHDL is the best bet if you are doing professional FPGA design, especially in the gov't/mil/aero/space industries. There is a lot of legacy code in VHDL and you're more likely to buy IP cores in VHDL. It is quite wordy, but the strong typing saves debugging time.
But for hobby or commercial use, Verilog is the clear winner. Verilog has much better FOSS tools (I never could get isim or freehdl to work right, and I do this for a living). The openHPSDR firmware is all in Verilog. The weak typing makes Verilog easier to learn, and it's more compact. System Verilog is a fantastic advancement and offers much that VHDL doesn't. I suspect everyone will be writing their testbenches in system verilog (or perhaps SystemC), even if the synthesizable code is in VHDL. Might as well learn just one language and do everything in Verilog.
Schematic capture will limit you; it's fine for small-time hacking but if you really want to learn this stuff you can't beat an HDL. Also be careful about graphical tools like LabView, CoreFire, Simulink, etc for FPGA design. You'll end up only understanding that one proprietary design entry language and won't be able to share designs and knowledge with the broader world.
VHDL is powerful but is too general. Basically, you can make the language do whatever you want, (not just limited to gate code, but any sort of modeling or computation, period), but it's a pain in the ass to do it. Pretty much all the operators and symbols (even '1', '0', 'h', etc) need to be defined before you can do anything, making it a feat to actually get work done. Well, there are standard libraries for stuff, but there are issues with multiply defined symbols and stuff in different libraries.
VHDL is very verbose and requires a lot of boilerplate code to do the simplest tasks. That said, it does scale reasonably well.
I think Verilog is more specifically geared toward FPGA gate code, and so it's a lot simpler to use. You don't have to fight the language like in VHDL. Go Verilog.
I've found that Verilog is much easier to learn and teach (at least, for an undergraduate engineering-type class). But, as others have mentioned, do NOT think of it as a programming language. Think of it as a convenient way to draw schematics, a very sophisticated keyboard layout for Xilinx. You should ALWAYS write synthesizable code for everything except your testbench, and you shouldn't have to synthesize it to know what it looks like. As to why not VHDL, well, VHDL is the COBOL of HDLs. Way too verbose for me.
My Systems
VHDL has an incrediablly anal-retentive type system and has some silly ideas like the splitting of entities and architectures. It's also old meaning you need a lot of boilerplate to manually import STD_LOGIC stuff (which is what the synthisis tool vendors tell you to use for everything)
Whichever you use be aware that both VHDL and Verilog weredesigned as hardware simulation languages not hardware synthisis languages. This means it is vital to get to know the synthisis tool you will be using. It is vital to know what warnings matter and what can be safely ignored and which are important, what parts of the language must be avoided, how to assign clocks to clock nets, how to use the timing analyser (without timing alalysis you don't know if your code will actually work) and so on if you are going to use the languages for FPGA programming.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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
http://www.altera.com/products/software/quartus-ii/subscription-edition/qts-se-index.html
Everything we ever tried to do using Quartus was overly hard. Every time we needed to assign pins or select a device Quartus would either fail or it's servers JTAG would crash or we'd have to reboot Windows. I don't want to rip this appear but as a moral and ethical person I had to inform you of this.
Quartus can help with Vhdl and Verilog for sure. I'm not saying it can't but everything you'll ever do with it is made 10 x harder and more complex then it ever has to be. If you going to teach students make sure to say away from this software!
Then the language is almost irrelevant. A good developer, software or hardware, can use just about anything thrown at them to accomplish the task, given a reference manual for the language. FPGAs are just another form of programming and should be treated as such. (Or you could say that software is just an extension of hardware and should be treated as such, doesn't really matter which way it goes).
So, to answer your question. At this point in time, for you, which one you use depends more on non-technical issues such as what hardware you're going to be using to do the initial development. If you can find a Verilog compiler but not a VHDL for the hardware you're going to start with then the question answers itself. For instance if you were going to use an ATmel FPGA, you're most likely going to be using their workbench and the language it uses (Cant remember off the top of my head which it actually is) as it contains the best integration with the hardware for development and testing purposes. It would be silly to try to use the other language with an ATmel FPGA unless you already have a large base of components built in that language to port, which if you already had that base set of components, you would already know the answer to the question you ask.
When you get to the point that which language use you actually matters, you'll be fully aware of it and at that point you'll actually be able to make a decision. This is true for just about every programming language on the planet, hardware or software. The language matters a lot less than most programmers think. The reality of it is, most programmers suck ass, and the reason they are so loudly voiced about 'their' language and all its 'greatness' is because they don't really know how to program, they just know enough to make their preferred language do something useful. At the extremes of programming its a little different. If you're talking about writing software for a micro controller with no memory management support and/or tiny amounts ( or no) ram, then using Java would be dumb (even if you had a VM already). C makes more sense, but with little ram, it may waste too many resources there as well, so you're going to be using assembly in most cases anyway. When you're working on a Mac, Linux or Windows desktop PC however, those sort of limitations simply don't matter to most apps, so any language will do until you come up with a reason the language won't work. Since you know very little about the languages involved at this point, you probably can not make a educated choice at this time. Even when you do start running into limitations, its likely going to be the same for both languages or a compiler issue. For instance, there is no 'reason' a C# app can not be as fast as an app doing the same thing in assembly though it does happen. It happens because the compilers used to turn C# into actual executable code that the processor understands in not nearly as effecient at generating machine language as an assembly programmer doing only EXACTLY what it has to do and taking advantages of the way the machine itself works.
With Verilog and VHDL its all just gates in the end. At this stage its practically impossible to determine which one will be more effecient for you to use. You're coding style, your abilities, the quirks of the compilers, the ease of use and understanding of the tools all matter far more than anything else. You'll see plenty of slashdot posts exclaiming which one is better, but the reality of it is, you won't know which one is better for YOU and YOUR PROJECT until you get some experience. Unless you plane on laying out your entire game plan, what you are building, how you intend to go about it, what hardware you're using and EVERY other specification about your project, than any advice is just a guess and not even an educated one. Someone may say 'Use VHDL, it does X, Z, Y, and really is easy to use thanks to feature B'. Feature B sounds important, so you use VHDL. Turns out that you never use feature B, and becau
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
This might be offtopic, but while we're on the topic here, does anyone know of any *afforable* FPGA kits for students?
Our university used the Altera DE2 boards, found here http://users.ece.gatech.edu/~hamblen/DE2/
I really liked the DE2 because it has a whole lot of peripherals and can be used with Quartus II. I wanted to get one so I could tinker with it in my own time for fun.
Any recommendations for one less than $500~ ?
Like http://www.myhdl.org/doku.php. It's basically Python and can be translated to either VHDL or Verilog.
The industry seem to be leaning toward higher-level languages like MATLAB/Simulink, which let you generate automatically VHDL code for your FPGAs from an higher level functional schematic diagram. So you might want to include them perhaps towards the second part the course.
We learn from history that we learn nothing from history - Tom Veneziano
Verilog is more concise. Example: 16-bit LFSR counter in Verilog has 24 lines of code. The same in VHDL is 41. (I generated the LFSR counter using OutputLogic.com online tools)
If you like the ADA programming language (Yuk!), then choose VHDL. If you prefer the C programming language, then choose Verilog.
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
I learned VHDL at the University of Texas. It has got to be the ugliest language I've ever seen.
Last quarter i took digital design at university of cincinnati and we used verilog, i found it much easier to understand than VHDL. I would say go with verilog if you are just starting out.
I have already taken a Digital Systems Design class and we used the exact same Spartan FPGA board. I am a freshman at the University of Cincinnati, and they made one very large mistake when scheduling this course. We were required to take this course before taking our introductory to C++ course. This made learning Verilog extremely difficult having had no programming background and the teacher was assuming that we all knew C pretty well. The book we used was Digital Design by Mano and Ciletti. It was a rough course for my classmates and I but I'd be interested in hearing your ideas to teach the course. Of course the only other downside is now that I am past the course I'm stuck with a $70 FPGA board that I'm sick of looking at. Overall I would suggest focusing more on Verilog instead of 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
I don't see any holy war here.
Nvidia (only one that cares about OpenGL), Intel (Core 2 basically killed AMD), and Coke (has 15% more market share).
For those who remember Pascal programming language, Verilog has some Pascal elements.
For example "begin-end" blocks
- outputlogic
Visit outputlogic.com : tools that improve productivity
My first preference would be to have the course taught by someone with real experience with the subject. If it's going to be the blind leading the blind, it's better to not have the course at all.
Verilog is a programming language that describes hardware. You can program complex algorithms, protocol stacks, even simple operating systems. I've done it during my 9 years working with Verilog.
- outputlogic
Visit outputlogic.com : tools that improve productivity
VHDL is used by defense contractors still. Although its ADA based, it requires strong typing, making it less prone to error. Although its hard to learn at first, you eventually notice its a lot like working with a virtual breadboard of sorts. Verilog is used in mostly consumer devices, and ASIC design. Intel, AMD, and other chip companies use verilog to design their newer architectures, although it can be more prone to bugs than VHDL, neither language is absolutely perfect. This is why we have verification and test engineers write test benches for the code to find any errors in the design.
In this day and age, its best to know both languages. They are pretty much alike, just that some of the keywords and syntax is different. Most FPGA design tools come with soft processors made in VHDL or verilog, and the user will typically use C to create the for the processor to run your task, this alone also makes knowing C a requirement. VHDL and verilog in such projects would be then used to special tasks, like fast image or audio processing, since the VHDL or verilog module would be tuned for that task and be able to complete it in a very short order of time compared to a general purpose processor. If I can make any recommendations, the sites http://www.asic-world.com/ and http://www.fpga4fun.com/ are two places I would look to first when start learning about verilog and VHDL.
VIM
I see VHDL mostly used. I only ever see Verilog in third party libraries or autogenerated code.
I think language is an individual choice, but whatever you choose, make sure the students actually synthesize something on a chip and try to meet some timing requirements. Everything works in simulation.
Also, have them take at least one programming course. Firmware engineers try to write software as if it were firmware. Think variables and function names in all caps and absolutely no code reuse. I'm still fixing this guys terrible code.
Handel C is the best language if you can find it...
As a pure software geek working in a hardware environment, VHDL is prerferred. But equally - of it works, go with it. Verilog is accepted as valid as VHDL.
Consciousness is an illusion caused by an excess of self consciousness.
I'm an undergraduate student and just finished a course in VHDL implemented on the Xilinx Spartan3-series FPGA and found it highly enjoyable. Definitely don't attempt to cram both in one module as I have no doubt that would confuse the kids no end. Instead get them comfortable with one and take that a bit further. I found Verilog a bit less intuitive but I did spend less time studying it.
Ummm, no.
VHDL is a subset of Ada.
Verilog was created by a company actually doing chip verification.
Ada, as any good student of languages should know, is a clusterf**k. Why Modula-2 (one of the contenters) wasn't chosen for Ada is a complete mystery to me.
As an aside, I used to program a lot in Modula-2. It was great. But then, ANSI C came along, and between the C standard maturing, and the compilers getting smart enough to ask if you REALLY wanted to do "if (x=0)", C became "good enough" and Modula-2's popularity waned.
These days I mostly program in Python and Verilog. I would have even less hair if I had to do my logic in VHDL.
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
Time to shamelessly (neither VHDL nor Verilog) plug THUD. If you are a fan of parentheses (there is an "emacs" tag, above, after all), just imagine your LFSR components nicely bolded and stuff....
I work for an FPGA company. Both languages are going strong. You'd do well to learn both. My experience says if you want to work in government, especially military, it's pretty much dominated by VHDL. And Verilog is the prevalent language in telco and video design.
As a Computer Enginnering Graduate, with experience in VHDL (coded 32-bit RISC based microprocessor), I would say go for Verilog.
For one, the industry for which students need to be prepared, is using Verilog( I interviewed for Nvidia and they asked for Verilog, though they would "let" you code in VHDL).
For another, since you say you're aware of C/C++, the syntax is somewhat similar, easing the learning curve,
Hope, this helps,
Shubham Harnal.
If your target is synthesis for an FPGA I would go with Verilog. Here is the bottom line: Any synthesis function you could do in VHDL could always be done in Verilog with fewer lines of code and will look alot simpler. VHDL is very verbose. If you search the internet there was a neat article about a Verilog vs. VHDL "competition" where one had to synthesize a logic function (targeting real hardware) in a fixed period of time. Of the people that finished, those using verilog were able to yield results that could run at higher clock speeds with fewer lines of code.
Disclaimer: I've been using VHDL design & verification for ~10 years (but also Verilog, and Specman E, PSL, etc.) & I'm a bit of language geek
VHDL is more verbose, but more capable than Verilog. There are several points that in my opinion make VHDL a better language for teaching (and for design and simulation):
1. It's *MUCH* harder to shoot yourself in the foot than with Verilog. VHDL is strongly typed (which is partly why it's more verbose) and generally when you write code you're not going to run into weird problems. Verilog is a minefield by comparison. Even very simple code can have race conditions & may synthesize differently from how it simulates. When I took a Verilog course many years ago, the first thing they handed us was fridge magnet with 7 rules (do/do not). If you don't follow those you risk shooting yourself in the foot. Nothing like that is required of VHDL.
2. VHDL is a lot better for simulation than Verilog. Partly because of Verilog's problems, once you step away from the RTL design subset you run the risk of spending hours debugging stupid things that a VHDL compiler would've caught, or that wouldn't happen in VHDL. With VHDL you can write very sophisticated testbenches(1). As an example I've written some constrained random + coverage testbenches in the style of Specman (or SystemVerilog). Try doing that with plain Verilog.
3. Verilog is a very simple language. It's harder to write reusable code. It's much easier to create parameterized, scalable, reusable blocks in VHDL through the use of generics and generate statements, multi-dimensional arrays, etc.. In fact this is my default style in VHDL. If it can be parameterized it should be. This applies especially to FPGA designs where the design requirements are typically more fluid than in ASIC designs. Also making designs parametric forces you to think more deeply about what you're implementing and to get to the core of an idea which in my opinion leads to cleaner, more maintainable code (again IMO a big deal for FPGA designs)
Having said all that:
1) VHDL seems to be on the wane a bit and the bastard child of Verilog, a.k.a System Verilog seems to be everyone's favorite language. There are definitely benefits to System Verilog. It's a much better language than Verilog. The problem is that it is based _on_ Verilog and shares many of the problems.
2) As has been mentioned above a good designer should be able to pick up a new language quickly, especially the design subset and a seasoned designer should at least be able to read both languages. You _will_ run into both of them in your work even if your shop primarily uses one.
3) It's true that ASIC designers tend to use Verilog, while FPGA designers seem to favor VHDL
(1) BTW the reality is that if you're doing your job as a designer right, you spend *way* more time writing testbenches than writing synthesizable RTL
It isn't a secret in the EDA industry that VHDL gets much less developers attention than Verilog and SystemVerilog. In some products VHDL gets probably 1/5th time of Verilog and 1/20 of SystemVerilog (into which most resources are invested). Although the differences might be less striking in other fields, e.g. FPGA-related, it is still there. This leads to lower performance, bugs going unfixed for quite long time, few new features etc. So my recommendation would be to go with the market leader - Verilog.
I like VHDL better. Sure the learning curve is steeper in terms of syntax but due to its different syntax students won't be as easily tricked into thinking that things are going to execute sequentially.
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).
Disclaimer: I haven't gone through all the comments but quite a few to get the gist of suggestions
In school I worked my way on schematics in the first half of the course and was given a choice of learning either of Verilog or VHDL. I learned Verilog more because it was the language of choice in US. But, to tell the truth, people who learnt VHDL were able to translate ideas from schematics to code in a much more efficient way than Verilog.
I struggled with Verilog for the first couple of months despite having a very strong background in OOPS.. While I did end up making a career in Verilog designs, I still think VHDL is more structured as a language and a far easier transition from schematics to code..
Verilog though easy to learn will give you a far tougher time if you have a tendency of being a bit less systematic (VHDL forces you to be systematic) - probably more suited for testbench design rather than IC design.... That said Verilog is extremely flexible when implementing multiple threads / pipelines.
In the end however it boils down to what the students want to learn and different students will have different background in programming. I would probably make VHDL as the suggested choice but keep it open to students to choose Verilog if they are comfortable.
Much of the industry appears to be shifting towards Verilog but VHDL is still very common and is not going to disappear any time soon. If I had to make that decision I'd most likely choose Verilog because of this but it's not a simple, clear-cut choice.
When I used to teach Verilog to college seniors & grad students I saw the syntax similarity to C as a problem for many students. Every one of them had a strong programming background and were used to the sequential nature of software. When you let them loose with some of the Verilog constructs it will take a while for most of them to understand the parallel nature of what the language is describing - I can't begin to count the number of times I saw someone try to 'call' a piece of hardware as a process or part of a for-loop as if it magically appeared to calculate a single result and then vanished into never-never land. Blocking & non-blocking assignments will also cause countless headaches. So will the ease at which you can throw down massive amounts of hardware with a few simple lines of Verilog. You can and will see students make similar mistakes with VHDL but I believe the syntax differences can help limit the problems.
Ultimately, if the students need to use one in their career they will also need to use the other. No matter which one you choose they will easily be able to pick up the other as long as they understand what the HDL is truly describing.
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
I kid, I kid. Does anyone still use that language? FYI: AHDL was (is?) a proprietary HDL language designed by Altera for use with their FPGA. I had to modify a design that used it once. It was aweful. I'm glad I've never had to use it again...
Anyway, I don't think it really matters what language you use to teach. According to the summary, this is a university (i.e. higher education) course, not some college training course. Teaching the proper hardware (ASIC, FPGA, whatever) design concepts should be your real challenge; what language you use to convey those concepts, to illustrate examples with, and require students to use in their assignments, projects and exams is (I would say) incidental. Maybe you should teach both, or hell, maybe you should teach only in AHDL and then require that your students use only VHDL or verilog for their assignments and projects (just kidding; that would be really evil).
In university, my work-terms, and for the first 4 years of my career, I only worked only in VHDL (and very briefly in AHDL), as that was the language my school and employers used (I'm in Waterloo ON, which appears to have sided with the US east coast, which traditionally has been VHDL). 6 yrs ago I started work at another company that used only verilog. Becoming proficient at writing verilog from scratch took a little while (a week or two, tops), but understanding (the gist of) designs written in verilog took no time at all. In the grand scheme of things, learning a new language if you already have a solid understanding of underlying design concepts is practically zero cost. All you need to make a quick transition is a decent reference book (or the internet) to look up syntax and concepts, a deliverable, and a looming deadline to get you motivated. That's all I needed, anyway; I certainly didn't need to take any verilog courses. I would almost say that it's a much bigger conceptual jump to move from coding for FPGAs to coding for ASICs then it is to jump from VHDL to verilog or vice versa.
So, personally, I would say that you shouldn't worry too much about the language, as that shouldn't be the primary focus of your course. It's definitely a required component to your course, but not the primary one. Concepts such as concurrent vs. sequential (processes), component inference vs instantiation, blocking vs non-blocking assignments, sequential vs combinatorial logic, zero-delay vs timing annotated simulation, synthesizable vs non-synthesizable logic, and a crap load of other digital design, simulation, synthesis, etc concepts are relevant in both languages and must be well understood before you can really be successful at designing with either of them.
That's a great post. Even if everything you say is wrong or outdated, it's still a great post. By the time I get all the right answers to the points you raised, I'll know a great deal about the subject that distinguishes experts from dilettantes.
This entire thread is better than average, yet I'm nevertheless somewhat stunned at the number of people equating accessible with good, bloated with bad.
A C program filled with assert() statements is more bloated than a C program without them. I guess it's partly a matter of whose dime is funding the learning process. If you're a student, shooting yourself in the foot with Verilog's fast and loose approach is a good learning experience (according to some posters here). They might be right.
In my case, as an experienced developer shipping products to customers on a tight schedule without dedicated test resources, I'd rather not discover what Verilog allowed me to get away with after the product has already shipped. I know a lot about hardware, yet I have little formal experience with either VHDL or Verilog. Ultimately the customer doesn't care if my language of choice was bloated or not. I didn't write the VHDL component of this project myself, but I will end up maintaining it.
Not sure what to make of the convenient C-like Verilog syntax. I guess engineers get away with uniglot more than the average programmer these days. Does the VHDL formalism occupy so much mental bandwidth that it impedes critical thinking and design? I tend to think that on a hardware project, critical thinking is close to the critical path. Am I naive? Are there aspects of hardware design akin to writing a throw-away app in Visual Basic?
The last time I regarded syntax as a serious impediment was wrestling with a DSSSL style sheet. I wouldn't program in a language for eight hours a day with a syntax I actively disliked. These days this isn't much of a practical constraint, since I rarely program in a single language for more than a day or two at a go. It's been 15 years since I would eat, sleep, breathe a single programming language.
I'm also a bit shocked at the number of people who prefer playing fast and loose with integer sign conversions. I tend to want to shoot C programmers who think that way. It's bad enough that addition of two unsigned quantities is not monotonic (without size extension). And that's *before* confusion about sign type creeps in.
The surprise for me is that up until now, I had heard more about SystemC than System Verilog, which seems to be about 100 times more important. Hey, I learned something today on slashdot. Not quite sure where to file that.
Perspective of Chip Design Industry:
http://www.deepchip.com/items/dvcon07-02.html
The War:
http://www.cl.cam.ac.uk/~mjcg/Verilog/Cooley-VHDL-Verilog.html
The competition:
http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley.html
I used to design using VHDL. But, the moment I started Verilog, I did not look back again. VHDL is just verbose and counter intuitive.
*) THIS is a "holy war"
*) this means that my opinion is biased. But I live with it and even get things done !
*) VHDL is a dog, is prone to syntax nazism and looks bloated.
*) However VHDL is incredibly powerful, like PERL gone syntax nazy. You can do one thing 3 or 4 ways, as you like (when you know the several ways). This means that VHDL can do /anything/. Even a web server ;-D
*) Now, Verilog (in my perspective) is nice to get "things done" like in C. But like C it trades compactness and writing speed for clarity and stability.
For many years, I was heavy VHDL proponent. Then I changed jobs and switched to Verilog. I now prefer the latter, but not a much I prefered VHDL in its days.
When it comes to designing an FPGA course, I would now go for Verilog, for 1 reason only: the open source Icarus Verilog simulator. It's very slow, but feature complete for what you're trying to do. There are no usable free VHDL compilers...
Labview has extensive graphical programming capabilities for their data acquisition boards; however, I don't know how easy it is to use their software for FPGA programming.
Part of the reason is that Verilog, being much like C, is inherently procedural.
Huh? Verilog directly provides declarative and event-triggered logic.
In my second and third years of undergrad, we studied VHDL (one class each year). If I remember correctly VHDL is more based in the DoD attempts at standardization from the days when FPGAs were very first being developed. The professor told us that once we've got VHDL down, Verilog is supposedly very similar. Since that time, I've studied FPGAs independently on and off since they're really interesting. It seems that any tool capable of building systems off one can also build off the other. Honestly, I haven't even really seen any Verilog code...ever.
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.
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.
I work in the EDA field now, and first 4 years of my career were spent in Design Verification.
Based on what I see, VHDL is mostly on its way out. Most new innovations in design tools center around verilog. Due it its being more "free" as opposed to the super strict VHDL, its gaining popularity in the last bastions of VHDL, the european universities.
Nowadays all big design companies use Verilog almost exclusively, with only legacy blocks in VHDL.
So Verilog is the way to go, and also easier to learn. However beware, if you come from a software background, you will have difficulty adjusting to the "time" concept of logic programming languages. So brush up the design basics first, how to blocking/non-blocking statements work, and how does an "event" driven language work.
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
I used to do asic/fpga design in verilog and vhdl for a number of years as a consultant, then I taught digital design at university for 5 years, using both languages. As a number of the previous posts mentioned, it's vital to teach your students to think of hardware while writing the code. The language doesn't really matter, since you can easily learn the other if you need to. But I found that the students were able to do more sophisticated designs when taught verilog, as opposed to vhdl. I think that's because vhdl has a steeper learning curve - it's verbose and very picky. Verilog has a hidden learning curve because your compiler won't complain about some vital errors, as other posters have pointed out. Just stick with one language so that the students don't get confused.
It's really important that you master your hdl, do lots of practice designs, because you'll helping your students do lots of debugging in the lab. In the lab, I tell my students that they have to show me a working simulation (i.e. testbench) and a successful synthesis check, before I will look at their hardware for evaluation or debugging. I tell them that they should have a correctly working simulation before trying to download to the board. Unfortunately, they usually don't listen and have trouble debugging their designs. Sadly, I've seem this practice too often in industry as well. I give zero marks for simulation, they have to show me working hardware. FYI, my students spend about 20-30 hours per week working on their designs, outside of scheduled lab/class time.
Be sure to teach them about synchronous design, we get lots of strange attempts at funny clocking schemes (e.g. capturing input data) and inappropriate uses of resets. Keep changing your design projects every year, or else they'll just copy. Good luck with the course, it'll be a lot of work, but fun.
It doesn't really matter whether you choose VHDL or Verilog as long as you know what your synthesis tools are doing. Both languages are very different from C or other compiled languages in that C allows you to assume that statements will occur sequentially (and yes I know that statements may be re-ordered behind the scenes such that they don't break dependencies) whereas neither HDL will give you that guarantee. In fact, unless explicitly stated, HDL statements will all execute concurrently (and certainly won't wait for something like a clock edge).
.... end if;
when statements like:
if rising_edge(clk) then .... end if;
work just fine (and are more readable).
Now here comes the important part. You can write VHDL or Verilog such that your design will simulate perfectly (even without using simulation-only constraints like after statements in VHDL) but fail miserably when synthesized for an FPGA. In my experiences, this has almost always resulted from latches being inferred by the synthesis tools. This is where you need to know a little information specific to FPGAs; namely, code using latches offers no benefits over code using flip-flops when dealing with FPGAs. Much of the time, synthesis tools will just set up a combinational loop in the hopes that such latches will act as a they should (they usually won't) because most of the basic blocks that comprise an FPGA utilize flip-flops, not latches.
If you're interested in a good source describing how to write VHDL for FPGAs, I'd suggest looking at Jiri Gaisler's method: http://www.gaisler.com/doc/vhdl2proc.pdf
Also, avoid statements like: if clk'event and clk = '1' then
"Is not a sentence" is not a sentence. Well damn.
I am an undergraduate student at the University of Colorado and I can tell you that we use Verilog here. Verilog was easy to pick up while I find VHDL more difficult.
"undecidable holy-war question along the lines of ATI/nVidia, AMD/Intel, Coke/Pepsi, etc...?"
The first step for an undergrad student, before even attempting to learn anything complex like VHDL/Verilog would be to learn proper spelling of "holy war" in IT-related domains. :-)
Read my lips, it is spelled : "Vi vs. Emacs".
Now insigthful people can understand you
This is indeed an eternal, undecidable holy-war question...
I vote for VHDL. Recently Sigasi released an Intelligent Development Environment for VHDL which relieves VHDL's verbosity and heavy syntax. This IDE is very similar to Eclipse and Visual Studio. It even has hardware refactoring support.
If you don't care too much about syntax or learning a new programming language then there's an FPGA-module for LabVIEW which let's you program the FPGA using graphical programming. Then there's a xilinx compiler in the background which creates the bit-file for you.
This being /., I'm probably going to be flamed for this... :)
VHDL is easier to use than Verilog (for me, at least). Verilog only appears C like on the surface, and it is exactly this which will catch you out in the long run.
I would also disagree with Jake73's assertion that Verilogs syntax is more familiar. VHDL would be familiar to any who have used Pascal. (And, more to the point, VHDL is obviously a subset of ADA)
If you're planning to work in Europe, learn VHDL. If in USA, Verilog. Of course it's not bad to know both of them.
Fwiw, I vote verilog. There's a lot of legacy work done in VHDL, especially in government projects, but pretty much all new development is/has been/etc moving to Verilog, and with System Verilog being open source a lot of your verification tasks are even easier now. If you get a chance to use VCS, you can use C code and verilog together flawlessly. Verilog's rtl level grammar is easier to understand if you're at all familiar with programming concepts, and reads very much like C. Xilinx support for Verilog used to be pretty weak, but nowadays is on par with vhdl. I've worked with both, and find verilog easier to read because of the way that modules and interfaces can all be in a single file, where vhdl always had pieces more spread out, less contained modularly (though that might've been an implementation choice by vendors, dunno).
http://www.beanleafpress.com
For some empirical data that may be useful:
http://www.deepchip.com/items/dvcon07-02.html
The results, although two years old, show that Verilog is a bit more widely used.
I've used both, and I prefer Verilog. Good luck with your course preparation.
It's not open source, it's a free (as in beer) online service that does not allow you to download any source code.
I fully agree about VHDL making more explicit the fact that you're designing hardware, not writing code that gets executed sequentially.
I'd think that it would be best for beginners to not bother with timing tools while they're still beginners. It tends to develop the tendency to "over optimize" right at the start. For the most part, simple (ie, low-speed) designs will work well even without timing constraints.
It's like asking "C++ or Java?". It's not important. What is important is to understand the digital design concepts. Once you've gotten that down, the syntax you need to know in order to design synthesizable circuits in either language is actually quite trivial to learn.
I think Verilog is a cleaner language myself. ASIC designers generally use Verilog whereas VHDL seems to be more dominant in Defense and government designs.
Most good design books will provide both VHDL and Verilog examples. I would highly recommend "HDL Chip Design" by Douglas Smith. It's no longer in print -- and the used ones still sell for ~$200 -- but it is probably the best book on the topic you'll find.
Both are awful languages from a theoretical standpoint. Practically, the synthesis subset accepted by RTL tools renders them almost identical, although their spirits are actually quite different. VHDL is more verbose but has the more rigorous type system. I chose to teach it based more-or-less on a coin flip. Whatever you choose, your students' first employers will be using the other one, so it doesn't really matter. My class at Columbia can be found at http://www1.cs.columbia.edu/~sedwards/classes/2009/4840/
Except that those "tools and stuff that gets in the way" is exactly what they should be learning. Every single VHDL compile error isn't just a "we're being anal" message. It's a disconnect between what the syntax is describing vs the logic that it will translate to. Hardware design is anal; it has to be accurate down to every bit. There is no room for ambiguity and "trusting the compiler".
You can learn more about digital design concepts from VHDL compile errors than a week's worth of trial-and-error debugging of mistranslated Verilog.
You can't avoid timing in hardware. It won't work without a clock. Synthesis won't run without specifications on how fast the thing will run.
Consider teaching both. I'm a student and I've used VHDL in first semester and Verilog in second (a project). I've found very good book for students/beginners and it was fun to learn it with it, the book was Digital design and computer architecture By David Money Harris, Sarah L. Harris. http://books.google.com/books?id=5X7JV5-n0FIC&dq=digital+design+and+computer+architecture+solutions&printsec=frontcover&source=bn&hl=en&ei=T-EjSqP3NoWNjAe53b2rBg&sa=X&oi=book_result&ct=result&resnum=4
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
First the quick answer - for what you need to do/achieve, Verilog sounds like the right choice. Focussing on digital design basics and synthesis is, IMO, far more important and crucial for beginners than worrying about language constructs. Although I wouldn't take that arguement too far and advocate that schematic entry is an acceptable choice instead of RTL. VHDL or Verolog will not teach you digital design. Just like C/C++ will not teach you computer architecture. VHDL vs Verilog choice becomes more important when the project's size (people) and complexity grows. For large and complex projects VHDL offers far more powerful constructs like generic programming (unconstrained ports) and abstraction (multiple entity-architecture, configuration etc) and the verbosity/cumbersomeness of the language is easily offset by the benefits. I have been an avid VHDL user for over 10 years. For sufficiently complex projects I have been able to convince and convert verilog users to adopt VHDL except for my current project where some people still use schematic entry - SIGH.
Sun SPARC anyone? http://www.sun.com/processors/opensparc/
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
Yes sir, I'm fully aware that a synchronous design won't run without a clock. All I said was that you will get decent results even if you don't include timing constraints in your design for 80% of simple designs.
Synthesis, in particular, doesn't need to know about clock speed. You only need timing constraints for place-and-route (and translate/map if you enable timing driven map). Then again, there's all this fancy stuff from Synopsis, but the OP is a beginner, and very unlikely to be using the fancy tools.
Why not consider a HDL for the google generation :-)
http://www.myhdl.org/doku.php
This is Python used as a HDL - conversion to Verilog and VHDL included!
Jan
I don't think there's a single synthesis tool out there that will let you synthesize a design without at least a clock. Other timing constraints aside, without a clock specification, there's ambiguities as to how to synthesize it to synchronous logic.
Verilog gives you enough rope to easily hang yourself. VHDL gives you so little rope you'll want to hang yourself. As a vehicle for teaching H/W design though, I think VHDL would be better. It's much more explicit and rules oriented, and looks like you're describing H/W. Once you've learned VHDL, picking up Verilog is fairly trivial. I would think going in the other direction would be a bit harder. Language Bias Disclaimer: I've been using VHDL for 10 years, and Verilog for 2...
*sigh* OK, you win the internetz. I guess I've been doing it wrong all these years.
Well, if I have to spell it out for you, "more familiar" is meant to mean "statistically more familiar" since the vast majority of people learning HDL come from a C/Java/C# background in some manner. VERY few people have familiarity with Pascal and even fewer with ADA.
If taught right, the "appears like C" doesn't involve a catch at all. (and by your argument, the fact that VHDL appears like Pascal would involve the same catch) HDLs are hardware description languages. It is extremely important to make that distinction early on. The appearance of an HDL like a procedural language is not a catch if taught in proper context. But this is the task of the instructor and is not associated with the particular HDL chosen.
Quick searches of their course listings show that they all teach Verilog as an after thought. Many classes that mention Verilog in their course descriptions are actually listed as VHDL classes and don't mention Verilog at all in the course title. The most apt description of the mentality is: 'this is the good way to do it, but there are others that do it this way.'
Personally, at Columbia we were taught VHDL as a virtue of our professors being from IBM and having written the actual spice software.
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.
Any course that targets a specific tool moves from being a life-long asset to being an educational experience that lasts only as long as those tools or languages are in-style.
An HDL course should focus on the theory and practice of HDL. The choice of which HDL to use should be made based on which tool allows you to accomplish that goal as well as possible. The widespread use of both Verilog and VHDL make them good choices. But (I feel) that for most fundamental classes, VHDL involves too much unnecessary verbosity.
In more advanced HDL work, VHDL begins to offer more. But with Verilog-2001, still not quite enough.
Disclaimer #1: I work for Xilinx. Disclaimer #2: I used to teach VHDL, back in the late 90's. I too, voted on the IEEE effort for standardization on the synthesizable subset for VHDL, and boy what a waste of time that was. But I digress. Here are some cool reasons why VHDL is better than Verilog.
1. Recursion. You can write recursive hardware components that instantiate smaller versions of themselves. Recursion is cool, but tools hate it. The Xilinx tools complain about it, but will still produce the right hardware. Recursion can be used for Multipliers, adder trees, priority encoders, muxes, and just about anything where divide and conquer actually works.
Exactly why you should not use it. With FPGAs you may be able to get way with relaying on the synthesis tool to understand your intent but ASIC tools have a MUCH harder job. They cannot be optimized for the target library and have other things to worry about like clock-gating. An ASIC designer should assume the worst from the tool. There are also FV issues.
2. Attributes. VHDL attributes translate straight to EDIF properties, and let you do cool stuff like physical design in an FPGA, EDIF properties in the netlist let you do anything from selecting the power-on state of a flop, to setting the logic function of a lookup table (LUT), or setting the initial value of a RAM. Even better, you can pass LOC (Location) or RLOC (relative location) properties, allowing you to physically place the location of a component in the target device. You can even specify directed routing constraints that lock down the signal path to a specific defined route. Verilog will sort of let you do this, but only in a pragma (code comment). Hence creating relatively placed soft macros controlled by top level generic parameters is possible in VHDL, but not in Verilog.
Physical constraints should not be in the RTL. This coding style is endemic in FPGA designs I've noticed. In ASIC flows a separate engineer is usually responsible for layout and he/she will greatly frown upon these.
3. Compile time elaboration of constants. This sounds incredibly obscure, but is actually very powerful. During elaboration, constants are evaluated. Constants can be defined by an arbitrarily complex function call. These functions can perform arbitrary computation, as well as read and write files. A standard trick is to read a hex file from the design directory containing data to load into a RAM or a ROM. I use compile time function calls to do precomputation on stuff where I don't know the generic parameters in advance. An example of this would be a state machine to detect a serial unique word, with the states branches computed at compile time by function calls that calculate the state branches based on a unique word specified in a generic parameter. Or how about CRC's? You see people writing C programs to generate Verilog designs to calculate a CRC, but in VHDL, you can compute the parity matrices directly at compile time given a static CRC as a generic parameter. Once the parity matrix is generated, it's easy to generate the hardware to calculate it. It's a bit trickier to do error correction with a CRC, but also possible. These calculations are hideously difficult in Verilog.
Things like compile-time constant calculations will drive validation engineers nuts. Why would you not calculate the constants once with an external script, then set it in your design? I find your statement interesting because ISE has many code generators which do exactly that.
Verilog can very easily initialize memory from a file. However most ASICs do not support this so it is usually done to support validation.
Again the right tool for the job. Verilog/VHDL should model the logic, not support the calculation of any arbitrary function. This just makes things harder for the synthesis
I've used LabVIEW FPGA module to develop FPGAs before. I found it to be rather intuitive, but compile times were very slow. I've never used Verilog or VHDL though so I can't compare.
LabVIEW's FPGA module uses a graphical programming language named G, so you see what goes on visually.
I meant to say that in my first paragraph that Verilog has both procedural and concurrent structures, and that its C-like syntax tends to push people to use more procedural constructs rather than concurrent which lead to gross compiler assumptions and/or non-synthesizability. In order to avoid confusion, I would therefore suggest that the strong typing in VHDL makes it easier to understand digital design in the context of an HDL. Sorry about the confusion.
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.
From the point of view of a student I strongly agree with StandardCell. In my CS program I learned both VHDL (in our Digital Electronics class) and Verilog (in CPU Architecture). The familiarity of Verilog created more problems than it solved (especially for folks who didn't learn VHDL in their digital class), because people tried to think about it like it was C, and use it like C, it isn't C. Frankly, learning a new syntax is a piece of cake, compared to getting students with a background in programming to wrap their head around the concept of designing circuits. VHDL is structured in a way that forces you to think about the design from a hardware point of view. Verilog may be good for larger projects, that need the higher level of abstraction that it provides, but that abstraction is a stumbling block for beginners.
Yes, this is legal in Verilog and not in VHDL.
But is it the compiler's job to teach the student?
The two frameworks have equivalent issues here. Verilog just doesn't warn you about the type issues. But VHDL requires that you go through hoops to solve them. They BOTH require some level of understanding to solve the problem. That's where the instructor comes into it.
An instructor is good but honestly, I've learned more from the compiler than I have from my instructors. That's why I said it's good for an introductory language. After you've learned VHDL, picking up Verilog is easy because you're already aware of all the gotcha's even if your instructor forgot them.
And frankly, for most undergrad students, if they can be sloppy and get it to work (and then go drinking), they will. No matter how much the instructor emphasizes "this may or may not work, do it the other way and it's guaranteed to work", the students won't listen. It's great to have the compiler put a stop to that and actually force them to learn the design concepts.
As for time spent, I'll use an anecdote. For my advanced digital design course as an undergrad, we designed a 32-bit MIPS processor. I did it in Verilog and put it on an FPGA. Our school didn't spend money on top-of-the-line FPGA's so we didn't have fancy features like ChipScope or JTAG debugging. Instead we had to use logic analyzers (running embedded windows and crashing a lot) and spare pins on the FPGA (there were only 12 to spare) as a test mux.
We spent weeks sleeping in the lab debugging that thing. Couldn't figure out why bits 0-8 (or so we thought) of the instruction register didn't look right even though it was executing that instruction. Turns out that because we added an integer count (in the RTL) as an offset to the address of the counter to sequence through the testmux, the address became a 32-bit value instead of the 16 we specified. And because we didn't specify which bits were to be assigned to which of the testmux select lines, synthesis just randomly did it.
That was one of many many many things that would've taken 3 seconds to correct when a VHDL compiler told you to "stop". Instead it took 14 hours. I almost destroyed that thing out of frustration.
You must teach in VHDL. You need to teach Verilog.
While Verilog is slowly adding features from VHDL, it's like comparing basic to e-lisp. The semantic possibilities in VHDL are significantly larger.
However the most important thing to teach is good practice: solving the seven or eight basic fifo problems; async vs sync reset; various counter and adder types
Just as programmers need to grok how their code gets turned into ASM, HDL coders need to grok the underlying hardware items that their compiler will spit out.
And verification - where you can test and were you must review.
And why coding style matters for test (eg. a parameterised loop can be verified by induction - a case statement cannot).
Particularily for chips (vs fpgas) it's got to be right first time, every time. So you need "Code Compete" next to "Microprocessor architectures"
ps - I designed chips from the mid eighties to the early noughties.
-- Butlerian Jihad NOW!
What this should have taught you was to use simulation.
Simulation was fine. RTL simulation produces the code behavior exactly.
what about basic... without the "v i s u a l"... that would be a very interesting way to to program FPGAs... hey, tell you what? go ahead... GOTO not considered harmful anymore... I, GOD, give you permission and my blessing
The syntax of a good subset of synthesizable vhdl for beginners is no harder to learn than verilog and will encourage them to give things the right type like signed and unsigned from the outset. So I personally feel VHDL is a better language because it is stricter and holds your hand a little bit more than verilog. And yes I do and have used both languages in the real world.
Also pick up shell, tcl(a lot of tools use it), and python (for general text manipulation and powerful scripting).
Bet you have never done any hardware design. Combinatorial logic can easily be described in any HDL. The fact that the synthesis tool can extract clock events from the description is a plus! (And very desirable.) As far as requiring timing constraints ... most designs do not need them. But, this has as much to do with the design of modern FPGA's as much (probably MORE) as the synth tool. (Please do not forget that the PLACEMENT tool is actually the tool that attempts to match the timespecs in a design). Early FPGA's suffered in routing delay, every PIP (periperal interconnect point) added as much as a few nanoseconds delay. ...
Anyway, there are often tricks for getting your design to run at the required speed. Pipelining is one such trick, but it does tend to make your head spin as you try to verify the design and keep all processes synchronised!
I would much rather program in dfdl.vhdl. Unfortunately, it's doesn't exist. It's a language that I designed only because Verilog and VHDL both suck so much. I felt compelled to show how to make a hardware description language that doesn't suck. So I did. And here's a sample of what the code looks like: circuit parallel_multiply( bit in1, bit in2; bit out) { in1*in2 | partial_products; partial_products | reduce(wallace_stage,3) | reduce(wallace_leaf,2) | ripple_adder | out; } circuit reduce( bit in; bit out; circuit reducer, int reduce_to) { bit stage; in | stage; while( max(stage.count)) > reduce_to) stage | reducer | stage'; stage | out; } circuit wallace_stage( bit in; bit out) { bit vertical, carry, sum; in,vertical | compressorn_nm2 | carry,sum,vertical; sum | out; carry | out; } circuit compressorn_nm2( bit in, bit down; bit carry, bit out, bit up) { while( a.count > 3) in-,in-,in-,in-,down-('0') | compressor4_2 | carry+,out+,up+; in | out; down | out; } That could be difficult to read, esp. if you don't know the syntax. But one could just as easily write clearer (if longer) code than this -- this was just to show the power and flexibility of the language. The equivalent in either VHDL or Verilog would be at least twice as long. I would LOVE to be able to program hardware in this language, instead of having to choose between two languages that were written back in the stone age.
I used to lecture in all this sort of stuff and I now work for Altium creating training videos. If your course is on _using_ FPGAs then I'd encourage you to not stop at the VHDL/Verilog languages. You're going to have to ask yourself if you are creating a HDL programming language course or a 'Designing with FPGAs' course. There are a number of higher level FPGA design systems out there that can raise abstraction above the HDL and will allow you to build FPGA systems much faster than you could with an HDL alone. Take a look at what Altium (www.altium.com) offers in terms of software AND hardware - they have a vendor neutral FPGA development platform that allows you to plug in different FPGAs (from different vendors) along with a whole heap of peripheral boards. I'm happy to talk you through it all if you have any questions. Marty