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.

Drawing Circuit Diagrams - Update

Well, after a bit of wrangling with the EGB layout algorithm - things are working out!



There are still a few crossovers on the outputs of U8 & U9 which I haven't got to the bottom of yet...

Animation

To help get to the bottom of such things, I've implemented a bit of animation to show me how the layout is progressing at each step. Using python's generators to unroll the main layout loop was the key here. First, the circuit data structure is drawn, then after a small delay the .next() is called on the generator, and the circuit redrawn. This continues until the generator is spent. Pretty nifty if I do say so myself...

Improvements

At the minute, the layout algorithm is sweeping from the inputs of the circuit to the outputs. I'm worried that this won't be optimum for untangling all types of circuits. So, once I debug my EGB algorithm implementation, I'll experiment with the following to see what gives the best results:

• inputs to outputs


• outputs to inputs


• inputs to outputs to inputs

I'm also concerned about the initial state of the circuit data structures. Maybe I've giving the algorithm too easy of a time. The instantiations in the circuit data structure are more or less in the order that they are in the verilog file. Maybe I should mix-up the instantiation order in the verilog files. Or maybe have a switch to randomize the instantiation orders in the data structure...

I've also to trawl/profile the code and look for optimizations...

Next Steps

After playing around with the layout algorithm, I think I'll add a final stage to tidy up the drawing of the nets. Once I get something half-pretty going, I'll concentrate on parsing a bigger subset of the verilog language.

Wikis

Keeping Engineering Info in Wikis

I'm starting an experiment at work. I want to liberate the design notebook. And this revolution will be wikified.

If my group 'published' sections of their notebooks on an intranet wiki, I'm convinced we'd see lots of benefits. I realise that having a paper trail is very important for patents and such, but I don't envisage the wiki replacing the notebooks - rather that the entries in the wiki would be a somewhat more polished version of the more interesting and useful scribbles.

What goes in the wiki?

Lots of things. Solutions to weird bugs. Testbench documentation. I'd even suggest that an entry for every major new block in each project goes into the wiki, with the important legacy stuff added as we go along. The block info would detail how the block works and more interestingly, why the block is. More info than in an email introducing the block, but maybe less info than for a design review. Even technical questions in emails to you could serve as topic pointers for a wiki page.

I think it's the wrong place for sim results. It's wrong for block pin lists or schematics. It's probably the wrong place for anything which has to be copied from other sources to keep it up to date.

Benefits of Wikization

The obvious benefit is that all this stuff which normally lives in only one or two people's heads or inboxes is available to and searchable by the entire group. Another benefit is that writing an entry in the wiki should focus the designer, making them think more about what they're doing which should help increase the quality of our designs. It would also be a ready-made source for info and text for design review documents, datasheets, customer presentations and the like.

Resistance

There are a few drawbacks, though. The main one is getting buy-in form the rest of the team. I'm not naive - I know that if I tried to get it decreed that everyone has to use the wiki in the way I outline, it would raise eyebrows, roll eyes and be dismissed as another layer of red tape and beaureaucy.

I have a plan* though - I'm going to lead by example and people will see the revolution as righteous. I've started to put interesting stuff in the wiki and I'm starting to point team members to it when they come looking for info. They're eventually going to start thinking, "Hmm, Marty would know that, I check that wiki thing of his before I ask him". This is going to be cool for a while until they spot an error, at which time I'm going to lightly suggest that they get themselves an account and fix it up. They're going to see the benefits of the wiki and start adding information themselves and things will get cooler. OK, there was a leap of faith there, but there's no harm in trying it out.

Aside: We've also a Sharepoint site too, but this seems to be a place for dumping documents and todo lists. I'm going to have to think a bit more about how the wiki fits with it.

Initial Wiki Usage Observations

So. The wiki I'm using at the moment is Wikimedia, because that's what sysadmin kindly set up for me. I like the way it stores edit history. I am finding it useful.

The main problem I see is with engineering diagrams. There's no stable drawing plugin for that species of wiki. State diagrams and example timing diagrams have to be created elsewhere and uploaded as .pngs or whatever to the wiki. I don't like the fact that the master document for the diagrams is elsewhere, making it difficult for others to correct or append them. And even if there were a stable drawing plugin, would the drawings be of high enough quality to use in more formal documents?

I think diagrams are important in engineering documentation, and would love if the barrier for entering diagrams into the wiki was lowered. I'd love if we all had graphics tablets (or tablet PCs) and could just scribble a quick diagram only for it to appear in the wiki. I'm contradicting myself here a little, but if it's a tossup between no diagrams because its a pain in the arse to get them in the wiki and sketchy diagrams that need to be redrawn with more care for more formal documents, then sketchy wins for me all the time. I like diagrams...

Future

I think the future of our group has a wiki in it. Lets see how the experiment goes...

Resources

• twiki


• wikimedia

* OK, it's not really my plan, I robbed it from http://www.randsinrepose.com/ , or more specifically, his book "Managing Humans"