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?