At the end of August, I picked up a copy of “Beautiful Code” (O’Reilly, edited by Andy Oram and Greg Wilson) that was lying around the Verilab office.  I’d just finished the last Harry Potter book, and I was in the mood for some lighter fare.  I’m about 90% through it, although I skipped a couple of chapters entirely.

I had every intention of really studying and understanding the code excerpts, and I stuck to it for exactly one chapter. After that, I just couldn’t force myself. I’m sure that must say something about me, not sure I want to know what.

However, I enjoyed several chapters. My favorite by far is “A Spoonful of Sewage” by Brian Cantrill. It’s the story of hunting and fixing a lock order bug in the Solaris 8 kernel. I think a big reason for its appeal is it really is written as a story. And along the way, I learned about priority inheritance as a solution to a common resource starvation issue. To me, priority inheritance is definitely a beautiful idea. My second favorite chapter is “The Quest for an Accelerated Population Count” by Henry S. Warren Jr. The divide and conquer approach is another beautiful idea.

Other highlights: “Beautiful Debugging” by Andreas Zeller, “Multidimensional Iterators in NumPy” by Travis E. Oliphant (I almost skipped this one!).

A couple of chapters that I was really looking forward to after browsing the TOC were disappointing: “Subversion’s Delta Editor” by Karl Fogel and ”Distributed Programming with MapReduce” by Jeffrey Dean and Sanjay Ghemawat. I have a feeling I just may not be smart enough to appreciate the beauty here, but, well, I don’t.

The common element of my two favorite chapters is not that the code itself is beautiful per se, but rather the code embodies some non-obvious but elegant algorithm. The beauty is in the idea. So is the term “beautiful code” actually a vacuous, meaningless concept? No, I don’t think so. I think code itself can be beautiful: When a function, a purpose, a meaning, shines clearly, concisely, intuitively through an expression, that expression is beautiful in its own right; beauty in idiom vs beauty in idea. And if a language seems to offer such intuitive expressions regularly, you could conceivably consider that language beautiful.

But having said all that, I simply don’t believe that a crisp, sharp boundary between idea and idiom exists: Function is nothing more than interpretation of form. Language and thought are so deeply intertwined, and any concept can be considered at so many different levels of abstraction.

For example, the priority inheritance algorithm might seem to be far more idea than idiom, while a NumPy slice operator might seem more language bound; but the idea of a multidimensional iterator abstraction surely is not.

Of course, the complexity of “beauty” makes language and thought seem simple by comparison.

Every once and awhile, I want to convert a string to an enumeration in SystemVerilog.  Casting from strings to enums is not supported in SystemVerilog, but luckily, it is possible to implement a function to do the appropriate conversion using built in methods designed for iterating over the enum values: 

(more…)

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.

(more…)

Here’s a new English term I’ve just coined: reuseless code. It refers to code that was written in such a reusable way that it can’t be used in any way. Writing reusable code is a noble cause, but before you start it is better to clarify where, why and how you think your code will ever be reused, if at all. Skip this step and you can be sure that, despite your good intentions, someone else will have to rewrite the whole thing later on. You can also be sure that your code will be unnecessarily and overwhelmingly complex.

In a testbench different parts are likely to be reused in different ways. Standard interfaces are the number one candidates for reuse in the pure sense of the term; it is quite probable that they will be plugged in as is into an altogether different project later on. Data generators (i.e. an Ethernet packet generator), base class libraries and generic packages (register package) follow close. In fact, if you’re lucky enough, you will probably be reusing someone else’s code yourself.
(more…)

Those of you who are members of the SystemVerilog User Group (SVUG) may have received an email describing several upcoming events.  For those of you not on the SVUG mailing list, here is the info:

SVUG has a simple goal to advance the SystemVerilog language and accelerate the adoption of associated tools, methods, IP, and training. If you are a design or verification professional looking for a fun, informative way to keep on top of the SystemVerilog ecosystem, then you absolutely should register for a fall user group meeting at one of following locations:

USA	Europe
Boston, MA October 15th Cafe Escadrille	Cambridge, UK October 9th Homerton College
Austin, TX October 17th Cool River Cafe	Munich, DE October 11th Sofitel Munich Bayerpost
San Jose October 18th Maggiano’s

These great locations will stimulate your SystemVerilog intellect with instructive tutorials and informative presentations, wonderful food & drink and best of all - the chance to mingle with your peers and the industries’ top SystemVerilog experts.

Click here to view each location’s agenda and schedule.

Verilab’s very own Jason Sprott and Mark Litterick will be presenting at a couple of the events.  Jason is presenting in Cambridge.  Mark is presenting in Munich.  If you’ve got a bit of spare time and are looking to learn more about SystemVerilog and meet up with other SV users, this is your chance! 

Used well, the Aspect Oriented (AO) features of the e verification language can save you scarce project time and give you a solution that can absorb change. The trick, of course, is using AO well.

(more…)

I just saw the announcement for CDNLive! Silicon Valley, to be held September 10-12 in San Jose. I’d encourage you to attend. I had the opportunity to attend CDNLive! Europe in May and found it refreshing for a regional vendor-led conference to pack so much good material, interesting people and effective knowledge sharing into 3 days. There were over 550 attendees. The venue was great and the tone was appropriately ‘real’ for a developers’ conference.

(more…)

[NOTE: This entry was written in response to some comments posted to my previous entry "Checks or Functional Coverage?". It was only meant to be a couple of line, but got a bit out of hand ]

In my previous entry "Checks or Functional Coverage?", I made the point that checkers were more important than functional coverage, and that you had to get the checkers done first. Some of the replies said "I agree, but…" and then went on to say that we needed both. I completely agree; the ideal testbench will have checkers and functional coverage. My message here isn’t "do checks and forget about functional coverage". It’s "do the checks for the important requirements before the functional coverage for the important requirements, but do both of these before starting work on the less important requirements, because you might not end up with the time to do it all". That’s not very snappy though, so let’s go with "do the checks first".

(more…)

31 July 2007 - Fixed a typo.

Why does no one mention checkers any more? All I ever seem to hear is “functional coverage”, “functional coverage”, and more “functional coverage”. It appears that the entire verification industry is in the midsts of a functional coverage love-in that, while might be good for tool sales, isn’t very good for some verification teams.

The historical reasons for this are clear - EDA vendors had to sell new tools, so they went on a functional coverage marketing campaign. They had nothing really new to add to checking, but they sure had those fancy constraint solvers with functional coverage engines to sell. And slowly but surely, functional coverage took centre stage in everyone’s minds.

But it has gone too far. Functional coverage has become such a central pillar of verification that we’ve encountered teams who can tell us in gory detail what they have covered, but can’t tell us what they have checked. In one case, they hadn’t actually checked anything, although they did have 100% functional coverage (which turned out to be wrong anyway).

A quick look at the SystemVerilog LRM suggests that the checking requirement seems to have escaped the language designers as well. Sure, SVA is wonderful, but assertions only go so far towards checking a design (and not really that far when you think about it). What about support for all those higher level checks? Where are the language constructs for checking behaviour and reporting errors in the testbench part of SV? “if()” and “$display()”? Is that really it? That’s not what I was expecting from a language that has been designed for verification.

The functional coverage mantra is so engrained in the verification industry’s psyche that even non-tool vendors are preaching it. Let me quote from Janick Bergeron’s [1] "Writing Testbenches using SystemVerilog":

"Start with functional coverage …Thus, it is important to implement functional coverage models and collect functional coverage measurements right from the start".

He is not alone - I just happened to have his book to hand. Surely it should be something like “Start with checks. Who cares what the functional coverage is if you don’t have any checks? Who cares what the functional coverage says when your implementation metric is only sitting at 10% (e.g. only 10% of testbench code written)?”.

Experienced guys like Janick know that the checks have to be in place, but even the mention of checkers has faded so far into the background that some verification engineers don’t seem to know about them at all.

So what should you really do when writing your testbench?

• Select your most important verification requirements. Pick the ones you absolutely have to get done
• Write some stimuli for them
• Write some checkers and check them
• Once you get close to finishing the implementation that you have planned, put the functional coverage in
• Repeat, but for your less important verification requirements

The point where you start concerning yourself with functional coverage is the point where you start going from the implementation phase (typing in the testbench code) to the closure phase (running tests and debugging). Now sure, I know they overlap quite a lot, but the point is that you get the checks in first because they are important. Functional coverage is a metric - passing checks are a necessity.

Look at it this way - if you had to run a testbench that had checks but no functional coverage, or a testbench that had functional coverage but no checks, which would be better?

Checks - no question about it.

So functional coverage might be the icing on the cake, but it will never be the cake. Checkers are the cake. You have to get the checks in first.

Cheers
David

[1] Ok, he works for Synopsys, but his testbench books are neutral and generic. Buy yourself a copy - you won’t regret it

Thursday morning at DAC I had the opportunity to speak with Larry Lapides, VP of Worldwide Sales for Averant about formal verification and Averant’s formal verification product Solidify.  Averant’s formal tools compete with those from Jasper, OneSpin, Cadence, and Synopsys, among others. 

(more…)