The world of open-source software is making inroads into areas beyond operating systems, Internet and desktop applications, GUIs and scripting languages. One less well-known area of open-source development is Electronic Design Automation (EDA) for Hardware Description Languages (HDLs). There are two main HDLs in use, VHDL and Verilog. Verilog is widely used for logic design and simulation in the semiconductor industry and elsewhere.

HDLs are languages for representing hardware, typically for simulation or synthesis. Representing hardware can be done at more than one level of abstraction, depending on the desired application. Looking at abstractions will help illustrate why HDLs are different from conventional programming languages like C, C++ or Java.

For the purposes of “what-if” simulation, hardware is modeled in the HDL by describing in HDL code what it does, e.g., how it be behaves electronically, not what it is, as a circuit. This kind of HDL code looks like a rather conventional computer program. A mid-level abstraction often used in HDLs is Register Transfer Level (RTL). This kind of code reflects a structural implementation at the level of registers (implemented with flip-flops or other bistables called latches) that have various logics inserted between them. The code describing the logic can be either behavioral or more like what would be used in an actual implementation. RTL is used first to sketch an outline of the system, then to mold it progressively into a detailed implementation. Through this refinement process, the code somewhat resembles macros, and designers may even take advantage of libraries of RTL logic. Logic circuits can also be modeled at a very low level, where the implementation of the circuit is literally described in code. This is known as structural design, and it can look like long listings of assembly language.

So, with only one language, all of these levels of abstraction can be described equally well, and mixes of them are often used in design. There's an even bigger difference between HDLs and programming languages: time. In a way, HDLs describe the ultimate concept of a “program counter” because they all model time so that the behavior of logic circuits can be properly ordered, for instance as clocks progress in a system. This leads to a very large difference in language semantics. HDLs are concurrent and effectively model parallel-system behaviors. For performance, HDL compilers are often implemented as C or C++ programs. However, the compiler implements semantics for a language that inherently describes parallelism because this resembles hardware more closely.

As a result, EDA tools that use Verilog tend to have some unique qualities and requirements when contrasted with traditional software tools. To put this story in context, we offer an interview with a leading open-source EDA developer, Stephen Williams, who has written the Icarus Verilog compiler under the GPL.

LJ: What is the Icarus Verilog compiler, and how does it work?

SW: Icarus Verilog is a compiler for the IEEE Standard 1364 Hardware Description Language Verilog(r). Those familiar with the the EDA industry recognize it as similar in concept to VCS, in that it is a compiler for a language that is commonly interpreted.

It works by parsing the syntax of Verilog into an annotated parse tree that is then “elaborated” into a design graph. The elaboration process instantiates modules, evaluates and propagates symbolic constants, checks the connectivity of all the devices and produces a checked, consistent design.

The design graph is transformed by various optimizers and logic synthesis steps into a new design graph that is more appropriate for the selected target, which is then scanned by the final code generator.

Finally, the code generator scans the design and generates the desired format output. For simulation, it generates C++ that uses a simulation class library included with Icarus Verilog. It also includes an XNF code generator for sending synthesized designs to further FPGA tools. I'm currently working on a loadable target code generator to support a variety of other target formats.

LJ: How long have you been developing Icarus Verilog?

SW: My logs show that it was introduced to CVS in November 1998. I had a few false starts for at least two years before then. If memory serves (and it rarely does), I think I was on the current path for close to a year before it got into CVS.

LJ: What was your motivation for developing this tool?

SW: The glib answer is that I have a Linux/Alpha system. That doesn't quite say it all, though. It is pretty obvious that Linux/Alpha doesn't get much respect from the EDA vendors, but it is also true that even Linux/Intel gets little attention. I just can't fathom why so many EDA vendors are so in love with Microsoft products.

My real reason is not so altruistic, though. Basically, I'm doing it because I can, and I can do it well. My set of skills seems well suited to this sort of project and, by now, even more suited. I'm coming through this with a much deeper understanding of the chip and FPGA design process than any software engineer should be allowed to have.

LJ: Why did you elect an open-source development mechanism?

SW: Access to my own intellectual property. I have done fairly large software systems in the past that I lost access to due to job changes and employee agreements. Although my current employer makes no claims to Icarus Verilog (it is understood that it is my own work on my own time) the copyright notices make that explicit, and this seems like a safer habit for everyone concerned.

Once the employer's potential proprietary interests are out of the way, I could have still done it as a closed-source personal project, but where's the fun in that?

Oh, by the way, having the source out there does seem to improve the quality of bug reports I see. I even get patches, sometimes including new ports or significant new features.

LJ: Who are some of the key people helping you with this effort?

SW:The README in the source distribution names names, but Steve Wilson has probably helped the most by managing the regression test suite. I've been told many times that the test suite is the most important single asset a compiler writer can have, and that is turning out to be pretty much the case.

I also deeply appreciate the bug reports I receive from users. They have been high-quality, detailed and almost always accurate. It is rare that I find that Icarus Verilog is right and the user wrong, and, when that does happen, it's pretty darn subtle.

I also use bug reports and change requests to guide my priorities when I'm trying to decide what to do next. They are also a great source of regression tests.

LJ: What are some of the typical uses of Icarus?

SW: Well, it's hard for me to know because I don't have a marketing staff finding this sort of thing out. My only source of information in that regard is feedback from those who choose to contact me—mostly, bug reports.

It seems that the users who work at large institutions may have limited access to the hugely expensive HDL tools, and they use Icarus Verilog to work on library parts and subsystems at home or on their desktop Linux machines.

I've heard from some people who have abandoned their commercial tools for simulation of small to mid-sized designs for a variety of reasons, ranging from pure cost benefit to pure activism.

Smaller scale HDL users might choose Icarus Verilog because it is good enough for what they need, and the price is hard to beat. It opens HDL design to those who would otherwise be locked out.

LJ: How might Icarus compare with a commercial EDA tool?

SW: Icarus Verilog is no real threat to the higher-quality big-name tools. They've got a bit of a head start on me. It was not long ago that I thought Icarus Verilog was not competitive at all, but I find that there are plenty of commercial tools that are even more unworthy of sale.

The differences come in the language coverage, simulation performance and synthesis quality. Icarus Verilog actually stands up pretty well with language coverage and is improving still. It seems to be about average.

Simulation performance is hurt severely by the performance of the g++ compiler that compiles the generated simulation. I'm afraid it was a mistake to generate C++ as an intermediate form, so over time I must replace it with straight C or an interpreted back end. Once the design is compiled, though, it runs reasonably well.

Synthesis in Icarus Verilog is not yet commercial quality, although some people are using it effectively. If you stick within the limits of the Icarus Verilog synthesizer, you can do nontrivial Xilinx designs. I know that some people for example have replaced Abel with Icarus Verilog in their design flow.

LJ: Are there aspects to proprietary EDA tools that make Icarus harder to do?

SW: For one thing, Icarus Verilog doesn't do everything that an EDA user needs. Sure it compiles to XNF, but you still need vendor-specific tools to map to and optimize for the part you are using. It has been hard for me to get needed interface information from the “layer below” vendors, leaving me to reverse-engineer Netlist formats. That is very irritating.

It also doesn't help any that the “layer below” tools commonly don't exist for Linux. This too is very irritating.

LJ: Does the open-source nature of Icarus Verilog provide some benefits over proprietary EDA tools?

SW: The most obvious benefit of Icarus Verilog over proprietary tools is the flexibility of your work environment. If you do a design that you know works with Icarus Verilog, you can be confident that you can buy a new computer, whatever is nifty this week, and expect to be able to use it.

I've noticed that EDA vendors are advertising licenses that don't expire, but the computer and OS you are running it on most certainly will. And, of course, Vendor X does not support Product Y Version 1 on the new system you just bought. So when you buy a new computer, you wind up buying software updates as well, and that is not only expensive but potentially risky if you are talking about, for example, a 95% full XC4013XL design.

(I've seen later versions of tools break existing designs.)

LJ: The commercial EDA industry seems slow to adopt Linux, although some have. However, EDA vendors seem to be especially reluctant to adopt or exploit open source. Can you speculate on why?

SW: Well, I imagine it might be tough to embrace open source if you have a $100,000 software product, but other than that I have no clue. All my coworkers at my day job complain constantly about being stuck with Microsoft operating systems, but there is no choice. The FPGA vendors are completely unresponsive to this particular gripe. I wonder if I can do an open-source place-and-router?

LJ: How much code is involved in Icarus?

SW: It's on the order of 50,000 lines of C++ with some C, lex and yacc thrown in. It seems to have stabilized at about that size for the last several months to a year. In other words, I'm removing as much code as I add.

There is also a test suite of Verilog code that is on the order of 300 small Verilog tests (16,000 lines of Verilog) along with a bit of Perl to drive it.

LJ: Can you suggest some improvements to open-source development tools that would be beneficial for projects like Icarus?

SW: Well, it would be nice if g++ compiled about ten times faster. I shouldn't complain too loudly though, as MSVC++ can't even compile my compiler. I've also run into symbol table limitations with Linux/Alpha and Cygwin32 binutils.

LJ: Linux is obviously a central platform for Icarus. How hard has it been to port Icarus to other platforms?

SW: I have precompiled binaries of the last stable release contributed by porters to Solaris, NetBSD and Mac OS. Recently, a Windows port was managed using the Net release of Cygwin32. The hardest part of all ports has been support for dynamic linking (HP/UX has been a major irritant on that score).

Basically, though, if you have a decent C++ compiler and GNU Make, you'll probably have little trouble with Icarus Verilog compiling for you. There is a FAQ page that shows some common problems and their solutions.

LJ: What are some other open-source EDA tools that Icarus users might be interested in?

SW: Well, there is certainly the gEDA tool suite (http://www.geda.seul.org/). And this page has links to a variety of other interesting EDA tools for Linux.

GTKWave is also a worthwhile waveform viewer. I always recommend it as a viewer that works with the VCD output from Icarus Verilog. The Electric VLSI Design System (http://www.staticfreesoft.com/) is pretty interesting, and, by the way, it does work under Linux/alpha.

The big list of EDA stuff is Open Collector, http://www.opencollector.org/. All kinds of nifty stuff can be found by browsing there.

LJ: Do you have any other HDL language support or features in mind for Icarus?

SW: Not at this time. I expect to keep up with the Verilog standardization process and that should be enough for one person. Even if I, by some miracle, “catch up” with the complete language, there will be all sorts of other aspects of compilation behind the language front end that warrant plenty of attention.

If I get bored, I might look into doing place-and-route. I need to figure out how to do that without getting too vendor-specific, though.

LJ: What would you ultimately like to see happen with Icarus?

SW:The same thing that happened to gcc, more or less.

If someone decides to pay me a lot of money to keep working on Icarus Verilog, that would be interesting, too.

LJ: What aspects of the project do you need help with?

SW: Code generators! I'm putting a lot of effort into cleaning up the API that code generators use. In my ideal world I provide a few core code generators, then let contributors do all the code generators for the various Netlist formats and simulation engines out there. This is much like how gcc works.

Regression tests! These are often scraped from bug reports, though I sometimes need to write a specific test for a feature I'm working on. The problem with me writing the tests is obvious, though.

LJ: What role do you think open-source will play with EDA tools?

SW: I don't really know. I'm not much of a sage, I'm afraid. At the very least, it should raise the minimum standards for the proprietary tools.

Also, I think open-source tools have the potential of protecting legacy designs. You can archive the source to your tools along with your design, but archiving proprietary tools seems pointless.

LJ: The mythological character Icarus had an unhappy ending. What is the significance of the name for you?

SW: You'd be surprised how few people realize this; “Icarus? how do you spell that?”

Besides the flying connection (I am a pilot, and, yes, I use FAA-approved feathers) it carries a connotation of more enthusiasm than sense. After all, I am officially a software engineer not a hardware designer. Okay, so maybe I can work an oscilloscope and logic analyzer, and I have been known to solder wires onto pins of 160-pin packages (adjacent pins), but the reality is I'm a software engineer flying too close to the sun. I've been told many times that a Verilog compiler is more work than I realize. I've been told that by hardware engineers. But not recently. I know what my limitations are supposed to be, even if I choose to defy them.

LJ: Can you tell us about the logo?

SW: Certainly. Steve Wilson can fill in more details, but basically it was drawn by a retired graphic artist, Steve's uncle. The artist, Charles Wilson, donated the design for the purpose of representing Icarus Verilog, and I appreciate the contribution. It's been used thusly ever since.

So you see, this Open Source Movement has a reach even beyond computer software.