On Write-Only Code and SystemVerilog Implicit Port Connections

At the iDesign II session, Cliff Cummings gave a great overview of SystemVerilog implicit port connections. Cliff was, as always, an excellent and enjoyable presenter. And the material was spot on, and current. But at several points during his talk, I felt like someone was scratching fingernails down a blackboard. It wasn't so much Cliff and his presentation. I'd have to say his was one of the best in DAC. Rather it was those subtle wee implications you can pick up if you listen really carefully to a presenter's ad hoc sidebars. Here then are Three Important Things I learned from Cliff (other than the undoubtedly useful details of how implicit port connections work).

The First Important Thing was Cliff's observation that the connectivity-intensive HDL top level of a big SoC is almost completely uninteresting to the human reader. While we have to get those connections down "on paper", few people will ever then want to read them. In "The Budding Artisan's Big Book of Beautiful Code Examples - Learn from the Masters", nowhere will you find a chapter on top level SoC connection code. The top level is, effectively, Write-Only code. In that respect, it's the opposite of what Don Knuth advocated with Literate Programming. The question is, why? The whole point of high level languages is to wrap boring, repetitive, typo-prone structures in an abstraction that protects the humans who have to write things down. The fact that SystemVerilog hasn't really figured that out (interfaces aside) suggests that the abstraction SV provides is, at best, leaky. Look hard enough at Java and you'll see, well, Java. Look hard enough at SystemVerilog, and you'll see wires, and flip-flops, and gates. Oh my.

OK, but so we still need the top level. And interfaces don't take away all the pain. Fair enough. The nice people at the Department of SystemVerilog haven't left us to wallow in our typos. There's a solution in the form of implicit port connections. If the ports on a top level instance have the same name and width as the wires to which they are to be connected, you can avoid the usual shenanigans of connecting them all up and instead just saying the magic words "dot star". Now I'm not a language expert, so take the following with a pinch of salt. But .* smells bad. My first reaction was similar to the one I had when I heard about the use of the * wildcard in sensitivity lists; namely, well why didn't they go the whole hog and give us full regular expressions?

The Second Important Thing I learned came from Cliff's explanation of why they didn't give us full regular expressions. In fact it turns out that the idea of expanding the simple * wildcard to a more complete regexp was discussed. See, those language committee dudes are clever people. The reason the language dudes (hurray) didn't implement the regexp's was because the tool vendors (boo, hiss) pushed back on the idea. Said those same Evil Tool Vendors:

"Hang on. Let's get simple .* going first, before we mess with the gore and pain of more complete regular expressions."

And of course, who can blame them? The key point though is that languages such as the ones we use in EDA are not developed in the cathedral-like purity in which things like Lisp and Haskell arose (if indeed even they did). Our industrial-strength, real-men-have-fabs, your-methodology-sucks-three-cheers-and-a-cookie-to-me languages have a large political component to them. Surprise, surprise. Let's get over it and just remember not to simply blame the poor language committees when they make something a bit smellier than we'd like.

The Third Important Thing was Cliff's explanation for the existence of the ".name" construct. Are you sitting down? (I was, which is just as well.) The ".name" construct is a compromise, made because your typical user of SystemVerilog is scared of the .* construct. Having that 2000-line piece of incomprehensible top level connectivity reduced to a 1000-line list of .*'s, is giving designers the world over the heebie jeebies. And the depressing thing is - Cliff is right! Partly because your typical chip head is a EEE graduate who didn't get the chance to write much code at university, and partly because his typical manager is an EE graduate who may not have had the chance to write any code at university, today's typical VLSI engineer is less comfortable with software engineering than is good for our craft.

So there you have it. Three Important Things I Learned Today:

1. The SV abstraction is leaky, especially at the top level
2. Tool vendors have more to say about language design than your average Joe Designer may realize
3. Average Joe is, however, taken into consideration. Specifically, the fact that he is not too smart on the software engineering front is a bigger factor than you might think

I can just hear the collective, "Well, duh!" resound across EDA-land.