h5. How did you get into electronics/ engineering and when did you start?
I started in traditional style: young! When I was about 4 or 5, my dad made my brother and me a board with some screw terminals, a 4.5V battery, a lamp and a switch. He tied a small screwdriver to the corner on some elastic and gave us some bits of wire. We had to make the light work. I thought this was the best thing ever!
Then on my 10th birthday, my parents got me an Usborne book of electronics projects. In the afternoon we went to Bardwell's - our local electronics shop. It was a grotto full of random bits of kit, and a counter-top *full* of assorted components! We bought a load of components, to make a crystal set and a burglar alarm. We even splashed out on one of those new fangled expensive *green* LEDs :)
Building the crystal set was a real experience - learning to solder onto stripboard and then hearing Radio 1 without any batteries, using the bedsprings as an aerial! That was me hooked for life. I went through my teenage years amassing more and more random components, a breadboard, and even an old analogue scope. Along with a collection of books written by RA Penfold - brilliant little circuits which inspired you to build them up and hack on them!
h5. What are your favorite hardware tools that you use?
* A high-bandwidth scope and good probes.
* A logic analyser that understands the protocols I'm looking at - I use a Saleae Logic, which is brilliant.
* Metcal soldering irons
* And I have to use a microscope for almost any soldering nowadays - my optician is amazed how bad my eyes are for my age!
* Finally - lots of mugs of tea (hey, I'm English, I don't understand this coffee lark :)
h5. What hardware tool do you wish you had?
I loved my TLS 216 LogiScope: 16 channels of 2GS/s scope with logic-analyser style triggering and bussing. One of the great bits was that it had two thresholds for the logic mode, so it would show an inderterminate level, which made it really easy to see edges which were slower than they should be. It would've made one of my recent timing problems crystal clear.
A good halfway house would be for boggo logic analysers to have two thresholds rather than one (anyone from Tek listening?)
h5. What are your favorite software tools that you use?
* Emacs - though I'm starting to be tempted by Eclipse...
* Python - if a language counts as a tool
h5. What's your favorite component?
I haven't used one in years, but probably the 555. I wish I'd had more time, I wanted to create a 555 out of 555s for the 555 contest!
h5. What would you be if not an engineer?
I'm not sure I could be "not an engineer", it's what I am, as well as what I do. But I'd love to be able to play music better than I do. (I'm hankering after an Eigenharp at the moment, truly an engineer's instrument as well as a musician's :)
h5. What is the hardest/trickiest bug you have ever fixed?
Don't know about trickiest, but certainly most fun :
Many many years ago, we had an electronic control unit which under certain circumstances (*very* slowly ramping power supply) would corrupt its I2C non-volatile memory by erasing a few bytes. Occasionally. Very occasionally! Once in a few hours of operation. After chewing through the software in enormous detail, we came to the conclusion that it couldn't possibly be the software. There was just noway to interrupt an operation and cause a write to take place at the time it appeared to be happening. To find it, I wrote a small piece of VHDL for an FPGA evaluation board that emulated the memory chip and triggered the scope whenever a write happened. We set that logging and left it to fail. Once it had triggered, the answer was perfectly obvious: One of the first tasks the software performed at startup was to read the non-volatile memory chip. As the power supply passed through the reset point, the microcontroller would reset a few times. The way the startup code of the micro operated, if the resets happened at just the right (or wrong) time, a read could be interrupted, and turned into a write. Following resets would then look like a single '1' bit being clocked into the memory, and eventually, the voltage would rise enough for the micro to stop resetting and continue, at which point a "STOP" condition was created and the memory would then write all the FFs that had been slowly being clocked into it during the resets. Thus corrupting the memory. Now these days, that'd be a doddle to find - with a tool like Saleae's Logic, you could trigger directly off a decoded I2C bus and see what was going on very quickly. But in the "olden days", we had to make our own triggers! ("Kids these days, etc.": Cue the Monty Python Yorkshiremen sketch!)
h5. What is on your bookshelf?
Lots! Some of my faves:
* Understanding Digital Signal Processing and Streamlining Digital Signal Processing: Rick Lyons - a brilliantly written introduction to DSP, and then a set of old-school tips and tricks for implementations which fit various scenarios.
* Hacker's Delight: Warren - superb collection of tricks like bit-reversing, counting ones etc, in minimal instruction cycles.
* Effective C++ : Scott Meyers - all the C++ stuff you need to know to avoid a lot of pitfalls. Especially if you started off treating C++ as "C with knobs on"
* Computer Architecture, a Quantitative approach: Hennesey and Patterson - loads of proper quantitative data on how micros are architected
* Bugs in Writing: Lynn Dupre - a collection of examples of "good" and "bad" writing, aimed at technical writing.
* A couple of TI databooks on CMOS logic, more for nostalgia - but I occasionally refer to them. Got my 1998 TTL complete databook, they've been virtually giving away, a brilliant bit of reference and nostalgia in one. I graduated just in time for the internet to supplant databooks like that.
* Hot air rises and heatsinks: Tony Kordyban - how to know enough about heat transfer to know when you need to start finding someone who *really* knows about heat transfer.
* And I'm just working through "Foundations for Microstrip Circuit Design" which is a bit more low-level than my normal fare!
h5. Do you have any tricks up your sleeve?
* Reading. Lots of reading. Especially old-school stuff. I have a great book on computer arithmetic, which is irrelevant to software on a PC, but still has some great nuggets for operating on small fixed-point micros. And some of the old ways of doing maths to avoid multiplications are great on FPGAs with very limited multiplication resources.
* Checklists. Lots of them!
* One of my hobby horses: remove *any* manual process that requires no thought from every part of your project. Script everything you can: builds, tests (I'm a fan of the ethos of test-driven development - not applied unthinkingly, but the ethos and thought processes applied intelligently), etc:
* If you do something more than once, script it.
* And finally - thinking! It's very easy, especially with software, to plunge away trying things: "I wonder if it's this". Stop, step back, think, instrument, gather data, think some more. Only then attempt a fix when you truly understand the problem.
h5. What has been your favorite project?
Developing a complex FPGA-based system:
Beginning a couple of years ago (at work), I created a new processing platform for our team to use. It consisted of a large FPGA, lots of DRAM, flash, ethernet and a flexible IO system which I could spin new IO boards for very quickly. I specified the system requirements and designed the whole thing: FPGA, memory, comms, IO, power supplies etc. Then I entered the schematic, simulated the memory buses, laid out the components, drove the autorouter, got boards fabbed. Someone else soldered the bits down - BGAs are beyond my abilities! Then I brought the board up from nothing: hardware, FPGA code, bootloader, flash programming, embedded test code. Finally, during the first project that we used the board for, I did a lot of the bring-up of Linux, ported the USB HCI chip drivers and the BlueZ bluetooth stack and sorted the boot process (including pairing with a smartphone, which was a bit of a faff to automate) It was great to get involved in so many different aspects of an embedded system - I really enjoy being able to apply myself to lots of varied stuff.
h5. Do you have any note-worthy engineering experiences?
Back in my teenage years, I built a periodic-current reversal battery charger for primary cells. It worked well, but had no timer. One day I inadvertently left some batteries on charge while I was at school. When I got home, the batteries had exploded and sprayed nasty black sludge down my bedroom wall! Sorry Mum!
h5. What are you currently working on?
I'm due to upgrade the embedded system I described earlier, so that will be a large chunk of work - I'm getting requirements specs together at the moment.
I also get involved in the specification process for the next release of the VHDL standard (which is the language I write all my FPGA code in currently).
In my (non-copious:) spare time, I'm collecting useful bits of VHDL code into a project called "libv"
h5. What direction do you see your business heading in the next few years?
More parallel. More configurable. Faster iterations.
h5. What challenges do you foresee in our industry?
Creating parallel systems reliably:
So long as we can avoid having to relearn all the great stuff that's already been learned about exploiting parallelism, we'll be able to progress. If we insist on using shared-memory and heavy(ish) threading, we're lost (IMHO). I recently built a relatively heavily threaded application where all the inter-thread communication was performed with mailboxes. Except for a couple of items which were forced to be shared-memory+mutexes. Guess which bits caused me pain? Grrr. I liked the design of the transputer - and its more recent close-relative (the XMOS architecture) looks really interesting. I've not found an excuse to play with it yet!
- The Way I Work: Interview with Todd Dust, Senior Staff Systems Engineer at Cypress Semiconductor
- The Way I Work: Interview with Bel Haba, an engineer with 400 patents
- The Way I Work: Interview with Robin Williamson, VP of Engineering at Teralytics
- The Way I Work: Interview with Adam Carlson, Aerospace Engineer at GE