I started my verification career using Specman. As such, I have a pretty good understanding of how to design a verification environment using e and Aspect Oriented Programming (AOP) techniques. Over the last couple of years I've been building my expertise in strictly OOP based environments such as C++, SystemC, and Vera. It's been a bit of a struggle, as AOP makes rapid prototyping of a test environment a piece of cake (relatively speaking). The reason is that AOP allows the creation of cross-cutting concerns that can be applied after the fact to allow the user to modify very specific portions of a data structure.
I occasionally read Joel Spolsky's blog - Joel on Software. Several of the posts over the summer described a project his interns were working on called Copilot. Copilot is a hacked up version of VNC that uses a central server to facilitate a connection between two machines that may be behind firewalls. It is supposed to allow you to either request help from someone or offer to help someone by directly logging into their machine. Fog Creek charges $10 for 24 hours of connection time. Sounded interesting. So when my mom called me at 9:30pm this evening (as I was getting ready for bed) with a question about why she wasn't able to open attachments in her email anymore I figured it would be worth a try.
Well, another few hours wasted screwing around with my software firewall. I've got Norton Internet Security 2005 running on my Windows XP-based laptop. I've also got VMware which I use to run EDA tools locally on my laptop so I don't have to go through the latency of a trans-atlantic connection (even with VNC it's not the best environment for looking at waveforms). Much to my chagrin, NIS has decided that it won't allow me to use the VMware NAT mode for my network connection but will allow me to use bridged mode. Unfortunately, bridged mode won't work if I'm connected to a network where I can only get one IP address. It also can be slightly annoying since the address can change when I pause a VM and then restart it in another location.
A common issue encountered in verification teams is a unix environment that is less than optimally configured. People often underestimate the productivity benefits that come from having a properly configured UNIX or Linux environment. I'm a big fan of IDEs like SlickEdit and InnerLoop (SlickEdit modified to support the EDA tools and languages). If you ever have the chance, watch a software guy who uses MS Visual Studio or Eclipse. If you're anything like me you'll have to ask why this type of tool isn't more widely used in hardware verification. Even without the fancy stuff, it is possible to improve productivity dramatically through the proper use of vim or emacs. I'm a vim guy -- as such I always make sure I have plugins such as taglist.vim and minibufexpl.vim handy. Vim also does interesting things when a tag file generated by Exuberant CTags is present. CTags can handle many languages including Verilog making it ideal for browsing and editing testbench source files.
In an article entitled The Usability of Open Source Software, David M. Nichols and Michael B. Twidale argue that many open source software packages suffer from a lack of concern over the usability of their program to the average Joe User. This got me thinking about whether the usability of open source software had any relation to the usability of EDA software. It's well known that there are still a lot of organizations out there writing Verilog/VHDL testbenches years after they stopped being state-of-the-art. The number of reasons for this are diverse and I won't attempt to address them all here. One possibility may be that it can be a pain in the ass to get some Verilog simulators installed and running let alone integrate them with tools such as Specman, Vera, Debussy, Simvision, etc.