Open Source, tools and solutions, are nowadays a given part of software development. Every day we hear about Linux digging new ground. GCC, the GNU compiler, supports more and more platforms and Open Source code gets into more and more products.
The same happens within the hardware market, though more silently. Last spring, I saw one or two articles about the OpenCores site that has been along for some time. Even so, I’ve heard little of it in my everyday work.
In this article I will look at the GNU HDL Simulator, GHDL. This is an open source simulator based on the GCC compiler. Using the compiler, it compiles VHDL code into an executable program. Running the program exercises the code. By built-in add-on code, you can get the waveforms that later is analyzed by any waveform viewer supporting the formats used. In my case, GTKWave is the viewer of choice.
I became curious on GHDL as it is an Open Source tool, providing me with an alternative to the tools that I’ve learned to know from my daily work. GHDL provided me a simulator that does not have the limitations of the free-of-charge versions of simulators from out silicon providers. The drawback is that you do not get the macro block simulation models of commonly used devices. Hence, I have to write these models myself. When I saw some hardware companies referring to the simulator on their home pages, I started to think about how I can benefit from it professionally.
An Open Source simulator you say…? Maybe you feel a little skeptical about the idea. What about provider support? What about quality assurance? In plain language, can I trust the tool to be well tested? If I find an issue, who will fix it?
Having a company providing you the simulator, if you are important enough as a customer, they will fix the problems for you. In other cases, you might just need to adapt. Looking at the quality issues, sometimes you may gain insights to the quality processes. Often, you tend to trust a tool since everybody else is using it.
The same goes with the Open Source tools… Since the Open Source tools are often used by a large number of developers, the limitations tend to be well known and the tool itself heavily tested. With this in mind, it is important to choose a tool that is supported by a large community. If the community is small, the tool may not be mature enough yet. Another important factor to me; is the project alive and how long has it been alive?
In the case of GHDL, the first downloads are from 2002 and the last release is done in July 2008. According to its home page, it implements VHDL according to IEEE 1076-1987 (VHDL 87) or IEEE 1076-1993 (VHLD 93). Event VHDL 00 and VHDL 02 are on the roadmap. It is said to successfully compile and simulate both a DLX processor and the LEON 1 Sparc processor.
My experience is: Open Source tools have a hard time gaining acceptance in my field of work. The arguments are many, often there are underlying quality issues as well as legal issues. For example, the GPL license is sometimes described as the lawyer’s nightmare. Over time the Open Source solutions have proven their quality, due to the masses of developers contributing, and started to gain ground within the software world. Today, the interest in Open Source formally explodes. Just look at the attention around LINUX and Android.
The commonly used simulator today often comes with high license costs. This is for sure an issue for small companies or the project working with dedicated licenses and tight resources. In these cases, I see simulators such as GHDL as an extra tool to speed up your project group. Having limited number of licenses means that developers will be pending on one another and the group becomes less effective. In this case, a free tool may be an answer to bring the team up to pace, still using the well known and commonly accepted tools for final verification. This way the project will be able to show assured quality with acceptable tools and at the same time waste no time waiting for licenses.
The setup would be that the team members use the free simulator for their every day development. Once the test bench of a certain component runs successfully and all test cases are covered, principally the work of the component is done. At that time, the developer uses proprietary accepted tools for a final checkup. (The choice of tool is of course depended on you customer.) This might be one way for a project team to cut cost and still be able to assure great quality even if anyone should doubt the quality of free simulators. However, over time, I would like to think that tools like GHDL will become accepted and supported just as GCC.
Mattias Almljung,
Embedded Systems Consultant, Altran Technologies Sweden AB