LJ Archive

A Conversation with Stephen Williams

Michael Baxter

Issue #99, July 2002

Stephen discusses the latest improvements and future plans for Icarus Verilog.

Michael What would you say the strongest improvements to Icarus were in the last year?

Stephen Oh, my—there were so many. I think the most significant improvement has been the simulation engine. By removing the C++ compiler from the Verilog compilation process, I've improved compiler performance several orders of magnitude. I've also made the compiler far more portable. The past year has also seen new compatibility with de facto standards such as library formats and command files. This makes the compiler accessible to more people.

Michael Icarus seems a lot stronger now. In particular, for simulation use Icarus seems to be starting to challenge commercial tools. Could you comment on how you see the quality of results for Icarus so far?

Stephen I never expected to be able to honestly challenge commercial tools, but here I am all the same. Commercial quality is the benchmark I use for judging my progress on Icarus Verilog, and I've made progress in that direction. Most of the feedback I've received in the past has been from people already using commercial tools who notice that Icarus Verilog does something wrong compared to the commercial tool, and that naturally leads to bug fixes that address limitations compared to the commercial tool.However, with the 0.6 release, the user demographics seem to have shifted a bit. I'm getting more and more feedback from users who do not have other tools. Who knows where this will lead. Comparisons with the big commercial tools are becoming less significant, though.

Michael What improvements for synthesis can we expect from Icarus in the coming year?

Stephen I keep hoping to make real progress on synthesis. However, no one wants to tell anybody how it is done, which leaves me to figure it out for myself. Fortunately, I have figured out most of what I need to know to infer logic for almost anything you can express in Verilog. Getting all the technical details worked out will be a lot of work, though.I'm hoping this coming year to get the combinational half of the synthesis all worked out. Quite a lot can be done in this case, and combinational synthesis may be the bigger half. Synchronous logic is a little harder but requires the information needed for combinational synthesis, plus some more.

Michael Today there are many more commercial EDA tools that are supported in the Linux environment. Has this situation affected users of open-source tools like Icarus?

Stephen So far, it appears not to have had a big impact. The set of commercial tools available in the Linux environment is still not complete and varied enough. Having a simulator for Linux is of limited use if your synthesizer and place-and-route tools are still Windows-only. I see that the coming year may bring some positive changes, with some recent announcements of Linux support promising some real change.

Michael IEEE Std 1365-2001, the Verilog 2001 language, still seems pretty new in CAD tools. Have there been issues between the 2001 and 1995 standards that you had to resolve?

Stephen The 2001 standard has resolved a few minor issues of the 1995 standard, but mostly what it has done is standardize, and put into writing, features that many compiler writers were already implementing. Some of the real tricky open issues of the language, including event scheduling, declaration scope and a few others, have not been addressed. The new features of the 2001 standard don't seem to be broken, and I've implemented some of them without any trouble.On the other hand, more complex new features, such as generate statements and configuration files, will likely be slow to be adopted. I know it will take awhile for me to get around to them.

Michael CAD tools often have external utilities to supplement them. You have supported some interesting external formats for open-source graphics tools, like GTKwave. How much work extra work was this?

Stephen Actually, GTKwave is a tool, and the format is VCD (value change dump). In this particular case it was very little work for me because the actual dumper code was submitted by volunteers. Most Verilog programmers consider waveform output fundamentally important; having a standard for the format and off-the-shelf tools to support that format helps very much.This is one of the advantages of standards. A standard that works allows for disparate vendors to produce bits that use the standard to interoperate with other bits. There are so many standards that don't work, we are surprised when we see one that actually accomplishes this goal.

Michael A year ago, compiling speed was an issue. Has the level of quality for the constituent GNU tools since then helped with improving the performance of Icarus?

Stephen No, they have not. The problem was not unique to the GNU tools, though. Compilation with Compaq and Microsoft compilers was at least as slow. The simple truth is that large C++ files as an intermediate form was a really bad idea.

Michael Do you have in mind potentially alternative forms of interoperability in Icarus? For instance, support for Verilog-A or other input formats?

Stephen I have learned to set realistic goals and remain focused. It allows me to make consistent, steady progress for years. The target moves, but it is always just a few steps beyond arm's reach. That means completing coverage of the Verilog standard proper is still the major goal.I have tried to design the interfaces to the core compiler and simulation engine such that related tasks can be done by others, though. As is the UNIX philosophy, I shall endeavor to improve the quality of the interfaces, so I can leave practical extensions to others.

Michael What factors do you feel have most contributed to the success of Icarus?

Stephen I've been lucky enough to have a combination of skills that allowed me to actually understand what I was doing. Once it succeeded past a minimal threshold, Icarus Verilog started to take on a life, and feedback became increasingly more common and useful. Many people seemed to want this, and encouraged me.Over the years, various people put concentrated effort into making patches and giving other forms of feedback. It's hard for folks to keep it up because no one (in EDA) is paid to work on free software, and free time is scarce and precious, so I managed and dovetailed the feedback the best I could.Surprisingly, I think the high price of commercial EDA tools probably has not been terribly significant. Much (but certainly not all) of the effective feedback I received came from people who have and use commercial tools. They know best when I've screwed up. Fortunately for those of us who can't afford those tools, that feedback is forthcoming and we all benefit.

email: mabaxter@pacbell.net

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 US patents in computer architecture and logic, plus five patents as a co-inventor. His interests also include hiking, amateur radio and programming in Lisp.

LJ Archive