A Conversation with Stephen Williams
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.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide