Open Source in Electronic Design Automation

An interview with Stephen Williams, the creator of the Icarus Verilog compiler.

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.

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.

Michael
Baxter has been working in computer technology since he
was nine, imprinted by a 1969 viewing of 2001: A Space Odyssey. He
is an experienced computer architect, system, board and FPGA logic
designer. Michael holds ten United States patents in computer
architecture and logic, plus four patents as a coinventor. His
Linux-related interests include open-source Verilog and EDA tools,
Python, automated source code generation, concurrency and hardware
issues.

Transfers from/to Lamezia airport and Paola train station will be
provided on the arrival days August 31 and September 5, and the
departure days September 6 and 12 with an established timetable.
Transfers are available also for the participants arriving to the
Airport with their own.

Registration fees

* One Week Registration: 250 euro.
* Both Weeks: 500 euro.

The registration fee will include, all Courses, Lecture Notes, Coffee
Breaks, Bus service from Lamezia Airport and Paola train station to
School Venue and viceversa, WiFi Internet Connection.
For the first 40 registered participant (before June 30, upon
presentation of CV) the registration fee will also include full board
accommodation in residence at Gran Hotel San Michele.

Accepted students may submit a poster and/or a seminar to present
their recent research activities.