How did you get into electronics/ engineering and when did you start?

I had a fascination with computers and electronics from an early age. At around the age of 12, when I saved up enough allowance money, I bought myself the original Sinclair ZX-80 computer, which I then hardware-hacked until it had to be held together with rubber bands to avoid falling apart on contact. After that, I had an Apple 2e, which I preferred because it had a top that just popped off; clearly it was designed for people to get their hands inside and mess around with it.

What are your favorite hardware tools that you use?

I’m partial to PIC chips, for the ease of use in a Linux environment, although the kudos go more to the open source hackers than to Microchip. Add to that the FTDI chips that convert USB to various serial interfaces, and the DLP-Design USB stamp using the FTDI chip, and it’s very easy to design a digital interface board for talking to chips under test. I have an interface board with a PIC programmed to talk SPI, SMBUS, and a proprietary single-pin serial interface. One PIC does it all.

Another piece of hardware I rely on is the ProLogix GPIB USB interface. It also happens to use an FTDI chip, and so it is easy to write software to communicate with all the instruments on my bench. It’s cheap, it has a small footprint, and it works (but, see below!).

What are your LEAST favorite hardware tools that you use?

Any lab instrument that’s based on Windows. Oscilloscopes used to be fast and responsive. They did what they were built to do, and they did it well. Now they’re all Windows- based, and when you press a button, it may or may not respond, and often-used functions are buried in cascading menus. The idea that the human-machine interface should be intuitive has all but disappeared, especially in the world of laboratory instrumentation.

I was going to tell about all the GPIB-enabled instruments I use in my “favorite hardware tools” until I thought about just what a pain it was, and still is, to communicate using a protocol that is so differently implemented from instrument to instrument that it is virtually impossible to make a platform capable of communicating with all instruments simultaneously. Not to mention THE worst design of a cable connector in the history of electronics.

What instruments are on your bench?

I should mention that my bench is in my basement at home: my own home laboratory. One cannot deny that eBay is a great source for putting together a professional-grade laboratory on the cheap. Instruments don’t have to be the latest and greatest to work well, and, per the comments above, older instruments often work much better, and are often better designed, with more intuitive panel controls.

My bench consists of a Tek11801B oscilloscope on loan to me from MultiGiG, two quad power supplies, one an HP6624A and the other an HP6626A; An HP5410A oscilloscope, an HP5385A frequency counter, and an HP3478A multimeter. In the middle of all that is a Linux-based computer driving the GPIB controller and the PIC-based board I mentioned above. That’s all I really need to do most of my chip testing for MultiGiG.

What are your favorite software tools that you use?

Well, naturally, my favorites are the ones I wrote or did significant development on. I use XCircuit probably more than any other single tool, including for writing out piano and violin scores, and for writing Christmas cards!

For lab use, I rely heavily on a Tcl/Tk-based software tool called “tclopto” that is similar to the Tcl/Tk interface I concocted for all the tools available on the Open Circuit Design website; it gives me access to all of my lab instruments and the PIC-based digital board that talks to my chips-under-test using Tcl commands. I can choose to set up lab experiments either as Tcl scripts, or as a Tk-based GUI.

What are your LEAST favorite software tools that you use?

Anything that requires a license server to run. I reserve most of my vitriol for Cadence, though. It started life as a cobbled-together mess of incompatible tools, and it’s still a cobbled-together mess of incompatible tools. Nobody in their right mind should pay so much for a tool with so many bugs that crashes so often, whose visual interface is unappealing if not outright damaging to the eyes, and whose user interface is laughable. Unfortunately, corporate interests do not follow rational rules of mind, so Cadence keeps getting paid and has no incentive to fix all the problems with their software. I don’t mean to pick out Cadence specifically, other than the fact that it makes the tool I’m forced to use at work for MultiGiG, because most of the other big commercial EDA players like Mentor Graphics and Synopsys are just the same.

Like Microsoft Windows and Microsoft Office, I can’t for the life of me understand why so many systems (even open-source ones) wish to emulate such an awful user interface.

What is the hardest/trickiest hardware bug you have ever fixed?

I do both hardware and software debugging regularly, and each has its unique problems, so I am splitting the question in two. Hardware bugs, especially with analog circuits, can be extremely tricky because the points you would want to test may not be reachable. Reaching those points by FIB (focused ion beam) edits is usually possible but very expensive, so there is a clear premium for clever ideas on how to indirectly test a problem point.

My favorite hardware bug story, though, is from my college days, and doesn’t involve chip-level debugging at all. The parents of a friend owned a computer store, and offered me some PC power supplies that were stone dead. Whenever they were turned on, the fuse blew immediately. I spent hours tracing out the circuit diagram on paper, at the end of which it looked to me like a perfectly good power supply, except. . . it just didn’t look right for a 110V supply. So I switched the supply from 110V to 220V, plugged it in, turned it on, and voila! A working power supply. What do you know; somebody had installed the switch backwards.

What is the hardest/trickiest software bug you have ever fixed?

Both Magic and IRSIM have had problems that I would look at, attempt a fix, fail, and then abandon for over a year before coming back to it and discovering that a fresh perspective makes all the difference. By far the most difficult program to debug is Magic, with its massive pointer-linked database and a one-delayed memory deallocation routine. I once got a test chip layout from an acquaintance that was so fantastically complicated that I have kept it as a sort of “GDS torture test”, and it took me years to remove all the instances of database corruption in Magic that it revealed.

What is on your bookshelf?

Recently, I read Douglas Hofstadter’s newest book “I am a Strange Loop”, but I was disappointed to find it rather lacking in new material. Probably the most interesting book I’ve read recently is “Moonwalking with Einstein”, by Joshua Foer, a journalist-turned-mnemonist whose journey to the international memory championship is a delight to read. My mainstay of reading is theoretical physics, which are often not on my bookshelf, literally, because I pick them up from the local library. Here I’ve recently read and recommend “The Trouble with Physics” by Lee Smolin; “Where Does the Weirdness Go?” by David Lindley, and “Reinventing Gravity” by John Moffat. Even if you don’t agree with them, you should still give an ear to those who dare to buck conventional wisdom.

Do you have any tricks up your sleeve?

Of course! I use Magic to create photographic-looking die plots of integrated circuit chips. I use XCircuit to create bondwire diagrams and datasheets, plus it’s useful for dashing off the occasional circuit diagram to share around by email.

What has been your favorite project?

My favorite open-source project has been XCircuit, since it was the one that I wrote entirely myself, from ground up, starting in the summer of 1993 when I started as a graduate student at Johns Hopkins. I was teaching an undergraduate EE laboratory course, and found to my dismay that the lab assignments were all mimeographed (yes, mimeograph!), I set out to redo the assignments in electronic format. I had been toying with the idea of writing my own drawing program for circuit diagrams, and by the time classes started in the fall, I had the program in good enough shape to use. Of course, it has greatly improved and expanded in the years since then.

Do you have any note-worthy engineering experiences?

I once accidentally deleted the entire email database of the Center for Speech and Language Processing at Johns Hopkins University. In a long chain of screw-ups and mishaps, I ended up with root access to their server, and not knowing that their filesystem was mounted on my computer, removed a directory that, in my opinion at the time, should not have been there. Needless to say, at least according to Murphy’s Law, the backup tape proved to be corrupted, and a full week’s worth of email communication to the entire department vanished into the Void.

What are you currently working on?

The most recent open source project I’ve done is a full open-source digital flow for custom integrated circuit chips. For a long time, I used this digital flow at MultiGiG, but the detail router was a tool that I obtained from an acquaintance for whom I had done some development work on the Magic layout tool. So I spent some time during the summer coding up a usable open-source detail autorouter. It is complete but fairly simple and is an ongoing project.

Can you sum up Open Circuit Design in one sentence?

Not really! I have long had an interest in maintaining and developing open source software, and over the years I ended up with some projects of my own, and taking over other projects. There were particular tools that I saw languishing largely due to being displaced by commercial tools, and this seemed particularly unfair because the open source tools were often better designed, and the commercial tools could not be modified to suit a particular need, or debugged when an error was found. When these tools had no obvious maintainer, I took over the job. Since I ended up with the better part of a design flow, I put everything together in a website along with documentation, tutorials, and other resources. That is how Open Circuit Design came to be.

Knowing that you have to read the above paragraph to understand what Open Circuit Design is, I’d summarize it in one sentence as follows:

Open Circuit Design exists as a resource for integrated circuit design, mainly targeted at three groups: (1) university programs, who have traditionally favored open source tools as development platforms for new ideas, (2) companies that cannot afford a complete suite of commercial tools, (3) companies that can afford the commercial tools, but wish to augment the commercial tools with open source tools that require no licenses and are often easier to use.

What were your goals with this site?

Cadence is still around, and is still overcharging for their tools, so no, the goals have not been reached, and probably never will. But seriously, I regularly get emails from all over the world from people using tools they downloaded from Open Circuit Design, and thanking me for the development and support, so there is clearly a strong interest in open source VLSI design tools. So in another sense, Open Circuit Design meets my goals every time I get an email from someone expressing their appreciation for the site and the tools that I help maintain.

What direction do you see your business heading in the next few years?

I am cautiously watching but generally supportive of the “Silicon Renaissance” initiative started by Ray Barrett and others, an attempt to recreate the heyday of VLSI design when multiproject wafer runs were cheap and common, sparking a huge number of forward-thinking projects. Most of those projects were, naturally, failures (not a few of those my own graduate school projects), all the more reason to support an environment where people (namely graduate students) can try out their wildest ideas without being product-driven. Someone, somewhere, will stumble upon the next big thing.

Open Circuit Design itself will survive as long as I can keep it going, hopefully to keep expanding its offerings whenever I have time. MultiGiG has been very generous in hosting the Open Circuit Design website, and I am thankful for their support.

What challenges do you foresee in our industry?

Overcoming a blatant lack of respect among management types for open-source tools. The perpetual availability of open-source EDA tools is never a guaranteed thing, and must be kept alive and well by the efforts of many, many dedicated volunteers, who must never forget just how fragile it all is.