Aligning With Emacs
In a company like Verilab, full of consultants smarter than a brain pie, it’s not often the CEO gets to teach anyone anything technical. So forgive me for taking advantage of a rare opportunity.
This morning (well, morning to me in the US, afternoon to him in one of our European offices) one of the team asked an emacs question on our lively, internal, intercontinental, questions-answered-almost-before-they-are-asked forum. Specifically, he wanted to know how to change this:
a0_af0_high = a0_af0_high.get_write_data();
a0_af0_low = a0_af0_low.get_write_data();
a1_af0_high = a1_af0_high.get_write_data();
a1_af0_low = a1_af0_low.get_write_data();
a0_af1_high = a0_af1_high.get_write_data();
a0_af1_low = a0_af1_low.get_write_data();
into this:
a0_af0_high = a0_af0_high.get_write_data(); a0_af0_low = a0_af0_low.get_write_data(); a1_af0_high = a1_af0_high.get_write_data(); a1_af0_low = a1_af0_low.get_write_data(); a0_af1_high = a0_af1_high.get_write_data(); a0_af1_low = a0_af1_low.get_write_data();
Such a simple problem, so many interesting comments and answers.
First, why is he even bothering about this? Who cares if the code is pretty? Answer - everyone with any sense. The most important reader of code is not the simulator but the next human who has to read it - including the author, three months from now. So, within reason, anything that can be done to improve readability is worthwhile. It is a constant mantra at Verilab that “Verification Engineering Is Software Engineering” and this is just one example of that in practice. Yes, it matters that you correct for metastability between clock domains; yes it’s important that if you gate clocks, you do it in a safe way; yes, it’s important that if you want a synchronous match flag to assert on the same clock edge that created the match you know which side of the relevant register’s flip-flops to look at. But on top of that, it’s important you code it right. Verification Engineering Is Software Engineering.
Next - why wasn’t he using an emacs major editing mode, which probably would have done all this for him. The well-known offering by the inestimable “Mac” was a good choice in my day. Well, turns out he *is* using the mode, it is Mac’s version, and, ahem, it’s not yet up to the task. Cue flurry of lisp hacking by Mac :-).
OK, so next - what’s the answer to the original question? Well, I came up with a simple two-stage approach. First, align the line-starts using “M-x kill-rectangle”. And then use the highly cool “M-x align-regexp” to align around those “=” signs. In emacs, as in Perl, there’s more than one way to do it. But those work.
And finally - how did I manage to figure this out? I mean, half an hour ago I didn’t know about align-regexp, I just sensed it would be out there. Why? Simple - I have had so much past exposure to emacs that I knew that someone just had to have done this before, so it was worth a search. And that raises a useful parting shot, still in the vein of “Verification Engineering Is Software Engineering”. One of the advantages of having a software view of verification (and, to some extent, design) is the tension it creates between the way much verification code is and the way it could be. The mature software mind has a language (perhaps some subtle combination of all the languages the individual concerned has seen, which is why learning languages is useful) in which to think about problems and in which to propose solutions. The whole notion of design patterns is an example of this in action. This is in contrast with the mind which sees the world only in terms of electronics. In that case, sometimes it’s impossible for the engineer even to articulate a problem to themselves, let alone posit an answer. It’s like an English speaker who has had no exposure to German (or to the 1727 edition of the “Universal Etymological English Dictionary”) trying to conceptualize “schadenfreude“. The software mind may have to tolerate for some time tangled code, tools that don’t respect each other and regression environments with more scope for bugs than the design itself. But the fact that it knows There Is A Better Way eventually has a positive impact. It is pretty much a universal experience of Verilab’s engagements with our clients that we start off working inside the client’s existing infrastructure, helping them solve their immediate problems in their chosen way, only to find, a few months down the road, client engineering managers peering over our shoulders saying, “Gosh, how cool is that; could you show everyone else how that works so we can roll it out across the whole team?”
