I have been asked on several occasions, why FMF favors VHDL over Verilog models. At the risk (or perhaps in the hope) of reigniting the great language debates, I offer the following answer:
In the beginning, when the founders of the Free Model Foundry were trying to solve the basic problem of how to write a simulation model that would not have to be rewritten when we changed EDA vendors, the issue of language was the first consideration. Our first choice was Verilog. Cadence had recently opened it to other EDA vendors and, of importance to us, Cadence also had a static timing verification tool called Veritime. Being able to write portable models that worked in both dynamic simulation and static timing analysis was an ideal solution.
So, we set off to create the models needed to simulate a board that was being designed at TRW where we all worked. The board used mostly ECL components. We found it difficult to model a particular feature of these parts. Many had differential inputs but could be driven as single ended by connecting the unused input to the part’s Vbb output. We had parts in the design that were run single ended in one place and differentially in another. We needed a model that could sense how it was connected and behave as the actual part would.
We could not figure out how to do that but knowing we were not Verilog experts we hired a third party company that was. However, they could not come up with a satisfactory solution either. A Verilog signal is limited to being 0, 1, X, or Z. Which one could describe Vbb?
We also needed to model a resistor in such a way that it would correctly function as either a series terminator or a pull-up/pull-down. This would seem to be easy for Verilog because the language has a rtran primitive. However, depending on the situation, we needed the output signal to be reduced in strength either one level or two. We found there was no way for the resistor to detect whether it was connected to a driver or a supply. Although Verilog allows the modeler to specify a drive strength on an output, it has no provision for reading that strength on an input.
The final blow came when it was time to netlist our schematics. It was 1994 and we were using Cadence Concept. Concept came with a tool named VlogLink that was supposed to create a Verilog netlist from a schematic. In 1994, VlogLink had so many bugs that it took a month, with on site support, to netlist one design. Then we had problems with Verilog-XL. We eventually got through the project but the engineers told us they would rather go back to debugging in the lab than to go through that process again.
About this time, the VHDL Initiative Toward ASIC Libraries (VITAL) was underway and about to release their preliminary spec. The purpose of VITAL was to add Verilog timing and backannotation capabilities to VHDL. We decided to give it a try. There were some bugs in the preliminary packages but we reported them and they got fixed. We found the ECL problem was easily solved by assigning the signal value ‘W’, which seems to have no other useful purpose, to the Vbb outputs. It is easy to check for ‘W’ on an input and modify the model behavior accordingly.
We wrote a bunch of ECL models and attempted to simulate another design. To our surprise, the Cadence VHDLLink worked fairly well. We had our design into simulation in a couple of days. The engineers found real design errors and corrected them. The process worked and the pain was manageable.
Admittedly, many of our initial problems with Verilog would not be problems with SystemVerilog. Indeed, we model some components now in SystemVerilog when we need VHDL like capabilities such as dynamic memory allocation. However, there is another problem of which we were ignorant back in 1994. Verilog portability, eh, well, it sucks.
It seems that Verilog was not designed to be a standard from the start. It was designed as a proprietary language. So if the LRM left out a few details, the (single) vendor would take care of them. But when you get multiple vendors, they will each implement those vaguely defined features in different and incompatible ways. Because VHDL had the benefit of being designed by a committee, and was intended from the start to become an industry standard, it does not suffer from such problems.
The end result is FMF writes models in both VHDL and Verilog/SystemVerilog. Our VHDL models run on all IEEE 1076 compliant simulators. Our Verilog models run on Cadence NC-Verilog and ModelSim. It was a major effort to get them to work on those two Verilog simulators. We will not even attempt (unless, of course, someone offers money) to port to any others.
And that is why we favor VHDL for component models even though we support Verilog. What do you think? Did I miss something?
Rick Munden
I have found it very easy to use Modelsim SE Verilog to run a verilog simulation with the fpga verilog rtl code, the fpga vendor IO gate level models, and the Verilog component models from the component vendors. I have found that is difficult to support a VHDL netlist, a VHDL wrapper, and mixed Verilog and VHDL component models and Verilog rtl code. There really isn’t any one simple solution, but having an all Verilog solution is somewhat easy to use and support, and may be quite desirable in the future.
Thanks for posting, and keep up the great work.
Brien,
You are correct. Life is easier if you can stay with a single language. Unless you can exclude external code from your design process, it will be difficult to stick to a single language.
If you can make the single language SystemVerilog rather than Verilog, you have a better chance. SystemVerilog has everything I can think of needed for hardware verification. However, it does not address the portability issues inherited from Verilog. Of course you may not care, how many Verilog vendors do you have in house? But companies writing models care that each model must be tested and customized for each vendor.
BTW, what is your experience extracting a Verilog netlist from a schematic?
While I don’t share the same experiences, I’ve come to the conclusion that VHDL fits my work best. VHDL was indeed designed by a committe, but initially for simulation purposes. The LRM does not even concern itself with synthesis issues, and this have initially been a drawback, but the language is very strictly defined in the LRM. The addition of standard logic signals and a few additional libraries have been crutial, the lack of fullblown standard of the Synopsys libraries is anoying, but since everyone supports them anyway it kind of work anyway. The VITAL adds crutial support for a structured annotation (forward or backward annotation) using SDF. Modern synthesis tools can handle much more than the original synthesis-subset. The recent AMS support is also good.
One reason for using Verilog rather than VHDL is that people claim VHDL to require much more code to acheive the same thing. Well, while VHDL may require more structure to be there, I think this really helps to keep curious bugs out of the code. In effect, I have very few VHDL related problems when I design and I beleive I talk to my fellow colleages. The amount of code is not a real issue either. Our problems is about actual design problems and solving them. When accustomed to VHDL you rarely make any major programming errors, it is more on the level of typos and you learn very quickly where they are, can clean up and can concentrate on actual design issues. I am not trying to imply that there would be any problem with Verilog in this context, just that what Verilogists often refer to being one of their objections isn’t a concern for us actually using VHDL. The argument evaluates invalid in my mind. Work fulltime in VHDL-only projects for a couple of years and write back is my hard judgement on that argument.
The VHDL LRM is a bit curious in its non-contextfree grammar, but once you picked up on that issue, it is actually quite clear and works well. The Verilog LRM that I have (Verilog-95) lacks a grammar and legal constructs cannot be found in the LRM and only if you know the history of C and C as such fairly deeply you can explain why it is a legal construct. How you are supposed to build compliant implementations from such a standard is beyond me. Over the years I have seen a decrease in compliance bugs between different VHDL vendors. I was recently supprised when I bumped into a compliance error in our synthesis tool.
We have no problem getting skilled personel or for that matter getting extra personel from the outside when needed. The universities here teaches VHDL and most of the other companies in the area uses VHDL extensively.
In the end, this whole Verilog vs. VHDL is not as much an issue of which language is best, but really which tradition you grew up with. IMHO VHDL is the best language, but the difference should not be that great. I can also for sake of honesty say that I don’t track Verilog very much and I really don’t see a reason why, VHDL does what I want, I can express my designs very well in VHDL and my issues are in general digital design issues as they should be.
Hi,
This is nice practical blog for using verilog in general and iverilog in perticular.
Check out other tool to give graphical view of your verilog code http://vlsi.cs.iitm.ernet.in/veriviz/index.html it is a totally new approch.
Regards
Hello! Good Site! Thanks you!