Thursday, July 16, 2009

I Program Computers

A new housemate moved in recently. We were getting to know each other - talking about our backgrounds, our favourite football teams and all the usual getting-to-know-you good stuff. He'd half remembered from our initial meeting that I did something vaguely technical for a living, and asked did I "program computers or what?".
"I'm an electronics engineer. I help to design the digital parts of chips", I NACKed.
"Ah", says he, "so how do you do that then?"
"Emm", I was caught out. "By ah, programming computers...", I sheepishly admitted.
It brings up a topic close to my heart - are Electronic Engineers (EEs) learning as much as they should from Computer Science and Software Engineering?

Digital Design is Programming

Software Engineering is important to EEs because digital designers, and especially functional verification engineers, are in essence specialised software engineers. For digital designers, our thoughts are necessarily grounded in hardware but those thoughts are expressed in software. The special requirements of concurrency and timing for describing hardware requires dedicated Hardware Description Languages (HDLs), but these are programming languages none the less - computers can be made to execute them.

If computers can run our HDLs as programs, then its natural as engineers to want to check the arse off our designs before they make it to manufacturing. We want to make sure that we've expressed our ideas correctly. We're obsessive about checking so we put our functional verification engineer hats on and we run simulations, and now we're suddenly programming for real. Our testbenches and testcases are now software proper. It no longer matters if the code we write is translatable into flip-flops and NOR gates, so long as the input signals are wiggled in the correct way and that the outputs wiggle as we'd expect. And even better (maybe?), we're allowed to abstract now.

I'm of the opinion that a lot of Electronic Engineers don't read enough about software development as they should. Software seems to be, or at least seemed to be, a minor detail that we could get the co-op to sort out. And as far as my own university course was concerned - why did I have to independently discover the joys of source control? I've read a few books like "Code Complete", "Emergent Design" and "Pragmatic Programmer" and wished with every line I read that an equivalent existed for us digital designers. Maybe there is, it's just that programming related resources are easier to find on the web.

Since we're all programmers now, we should learn how to program. From what I read, real software programmers seem to have a small niggling worry that they're somehow inferior to 'real' engineers. That's backwards though - us 'real' engineers need to start befriending real programmers and learn from them. We're so dependent on computers that we need to learn how to program for real. We need source control, we need unit tests, we need to learn to refactor and we need to learn to spot code smells. We need to write scripts to generate RTL, scripts to launch batches of sims over the network and create Makefiles to automate synthesis. We're software engineers and we haven't the slightest clue we are - at least, we've no ideal we will be when we leave college.


dallas said...

Hi Marty,

My verification experience is with SoCs that need to be spun derivative after derivative as frequently as possible.

Project/program managers in this situation often assume that testbenches can be "reused" with each new iteration.

Unless the testbench has been designed with "software reuse" and maintenance in mind (and by this I mean the use of object-oriented design principles, design patterns, and the judicious use of code generators) then you are actually saying "rewrite" not "reuse". (In fact, not just "rewrite one feature in one place" but "rewrite that one feature across the entire codebase".) There goes your cycle time improvement due to reuse.

So to save everyone's time put an actual software developer at the helm of testbench design instead of the guy who wishes he was writing RTL instead :-)


Marty said...

Now that's a very good idea! I wonder what it would take to convince a programmer to join a bunch of EEs. And I also wonder how EEs would go about hiring a programmer for that role? More specifically, judging competence in a skill we're not too competent in ourselves?

It's definitely worth thinking about though, 'cos I'm someone who'd rather be writing RTL!