Just a quick FYI… both David Robinson and I have posted our DAC presentations on Verification Planning and SystemVerilog Interoperability on the Verilab website. Please check them out and let us know if you have any questions or comments!
There was a recent surge of discussions about asynchronous clock domain crossings and metastability handling in Verilab email: Two people asked Mark Litterick essentially the same question just hours apart, and then a day later Jason Sprott noticed a Mentor CDC Verification paper that referenced Mark’s “Pragmatic Simulation-Based Verification of Clock Domain Crossing Signals and Jitter using SystemVerilog Assertions,” paper (Best Paper at DVCon 2006).
One particular statement in the Mentor paper caught my eye: "this model can still generate false errors: the waveforms show that input sequence A, B, C, D, E, F can result in output sequence A, B, E, E, E, where two consecutive inputs, C and D, are skipped". And this statement bothered me: I had spent a long time figuring out Mark’s model some while back, and while it was not at all intuitive to me, I did convince myself that it could never generate a simulated output sequence that was impossible in real hardware. So if the Mentor paper was correct, then I had missed something about Mark’s model, and I’ll be honest, I didn’t relish going back and studying it again.
Obviously I was just going to have to find a mistake in the Mentor paper instead. And to my considerable relief, I did. In fact, I found two:
SystemVerilog has two “similar” data types that allow variables to be grouped together in a handy package: the struct and the class. I’ve heard it often said, when explaining what a class (an object-oriented data type) is, that it is just like a C struct with functions. I used to have no problem with that, until, when reviewing and debugging testbench code, I started seeing some problems related to the way classes have to be treated differently to structs. One of the most common errors I’ve found is when data structures composed of classes are copied.
Consider the following: Read the rest of this entry »
I was having lunch with JL awhile ago, and we were talking about some recent Verilab email threads.
Participation in email threads is fairly high at Verilab: If you ask a question, you’re pretty likely to get an answer. Or three.
But even though participation is the norm, there is no guarantee that you’ll get an answer. There’s no guarantee that the person with the most useful knowledge will chime in. Well, these aren’t novel concerns, and there are tools to address them: Bug trackers. I’m rather a fan of bug trackers, and I think they could be used far more widely than is typical. And foolishly, I promised JL I’d write a blog on the subject.
So I started to organize my thoughts: My central themes would be the interface and the data model. I would argue that the bug tracker data model is far superior, but the interface is often far too cumbersome.
A bug tracker keeps state (and state history) and responsibility metadata. A bug tracker manages a to-do list, and if it weren’t a useful data model, then to-do lists would have gone extinct; and that ain’t happening.
Any communication that desires a response is actually an addition to someone’s to-do list: “Please respond”. And the vast majority of communications do desire responses: “Please book me on a flight to Aruba”; “What’s the Emacs keystroke for …?”; “I’m going to see the new movie on Friday at 8, wanna come?”.
Why not use a bug tracker for all of them?
Read the rest of this entry »
Folks interested in DFT would do well to head over to DFT Digest. In his latest post, John Ford ponders about the potential for hackers to learn information about the inner workings of a device via a side channel attack using scan chains. The topic reminds me of a presentation I attended at this year’s DATE conference in Nice. The presenter was discussing security issues and described how she wrapped her passport in aluminum foil to prevent would-be hackers from scanning info out of the embedded RFID chip.
Separately, John is compiling a list of DFT related links. If you’ve got some good ones to share head on over to his DFT Bookcase and or his DFT Forum and let him know!
SVUG started in March 2007 and has had a total of 8 meetings so far. It’s been a great first year for all of us involved with SVUG. The meetings and forum have been met with real enthusiasm. We’ve had some interesting technical discussions with new and experienced developers using SystemVerilog on their projects. We had some great presentations and tutorials, including me banging on about functional coverage, and Verilab’s Mark Litterick presenting some cool Assertion Based Verification techniques. We even managed to get some users to share their own tips and tricks, including our very own JL Gray.
I just got the stats for the fall 2007 meetings. 480 registered in total, 280 attended. Of the people surveyed (nearly everyone that attended the 5 meetings), 60% were using SystemVerilog today. Verification did pretty well out of that, with 67% of the share. Design got 10% and 23% said they used SystemVerilog for both design and verification. From a verification point of view another interesting stat was that 33% of the verification slice, were using the advanced testbench features of the language, and 32% were using SVA. It’s nice to see that more people are starting to use the HVL portion of the language for verification, not just writing assertions. I think this is due in no small to much better tool support and stability by all the vendors.
The growing attendance numbers of the SVUG meetings is a reflection of the interest and uptake of SystemVerilog by the design/verification community. I’m seeing an increase in our client projects using SystemVerilog Verification IP, and finding ways to hook SystemVerilog into their verification environments. Finally, it’s really beginning to feel like SystemVerilog is starting to make a bit of an impact.
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:
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.
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.
Read the rest of this entry »
