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.
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.
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.
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.
You forgot a few:
[--]VI vs. EMACS [--]
etc.
No, he didn't forget that. You see, he wrote:
(...Or is this an eternal, undecidable holy-war question along the lines of ATI/nVidia, AMD/Intel, Coke/Pepsi, etc...?)
... and it's quite clear that VI is the winner.
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!
I disagree with the statement that everybody has switched to System Verilog. I've worked with a few companies introducing it, and System Verilog is exactly the reason I want to go back to working with VHDL. It's horrible.
My take on it it is that a load of C++ engineers looked at Verilog and thought "What this needs is object orientation!" completely ignoring the fact that hardware description languages are OO by nature. After all, what is a module if not a method of encapsulating design leaving just a public interface.
The result is a horrible mess of a bi-polar language that can't decide if it's a software language or a hardware one, and the two sides don't really want to talk to each other. Add to that the fact that all of the design patterns that are being used with it are software patterns that don't map well to hardware, that most hardware engineers don't know, and you just get a big steaming pile when you try to introduce it to a company.
The EDA vendors love it because it's giving them a new set of tick boxes they can sell their wares on, but I've yet to see it do anything that I couldn't do in straight verilog / VHDL + a little PLI/FLI, and I've been working as a system verilog application engineer for one of the EDA companies. ...oh and it's really slow (as in orders of magnitude).
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