Previous month:
September 2005
Next month:
November 2005

Can't... Take... Much... More... Of... This!

My wife and I have been busy over the last couple of months trying to get our house cleaned up.  It's been a royal pain - we've only lived in the house for < 4 years and we've still chucked several bags of trash each weekend.  The whole process has been ripe for a blog post comparing messy houses with messy verification environments.  I was able to spend some time building up a mind map about it using Freemind this evening (thank goodness for the extra hour last night thanks to the end of daylight savings time).  I've also spent time over the past week trying to compose my thoughts about John Cooley's verification census.  And then there was that unfortunate incident earlier this week where I started some "minor" household repairs that are going to end up needing the assistance of a construction professional... Doh!  Oh yeah, and have any of you spent any time creating UML descriptions of your verification environments using tools like Umbrello or MonoUML

What's the moral of the story?  You might see a slowdown in the frequency of articles over the next week or so... rest assured I'm still here, just a bit busier than usual!

eRM for SystemVerilog? The Devil Better Get Out His Earmuffs!

It's been a long time coming, but it looks like the e Reuse Methodology is making the jump to SystemVerilog:

Link: - DESIGN LANGUAGES: Verisity verification tools tuned for SystemVerilog.

According to, Cadence will be announcing verification methodology and process automation software support for SystemVerilog.  I'm a big fan of eRM.  It enables engineers to share verification IP both internally and externally without having to worry about someone not understanding the way they've packaged their code.  It also promotes good software design practices. 

Continue reading "eRM for SystemVerilog? The Devil Better Get Out His Earmuffs!" »

If a Tree Falls in the Forest

Here's my random musing for the day - If a tree falls in the forest and no one's around, does it make a sound?  Or, in verification terms, if a bug exists in the silicon and no one will ever see it, is it a bug?  How much time should we spend debugging issues that can never be seen by customers?  Alternatively, how likely is it that the situation you thought never would happen actually will happen?  Best bet?  If it's not a bug, it's a feature!  I always like to see these types of issues resolved by adding a VERY STRONGLY WORDED STATEMENT to the architecture spec just to make sure the expected behavior is clear.  You could always use assertions to make sure no one tries to sneak something by you during system level testing. Alas, if the customer runs into the issue in real silicon, you're SOL! (Does that translate well?  If not, send me a private email at jl at coolverification dot com).

Comments Anyone?

Lots of hits this week, though the only comments I received were those sent back privately to my posting on the Specman User's Group.  Is it possible that everyone reading my blog agreed with everything I had to say?  Not likely!  One reason people may not be posting comments is they may not want to share their email address (currently required for posting a comment).  Fair enough.  If you're active in the blogosphere you'll be aware of the big problem with comment spam.  Comment spam is just like regular email spam, but consists of people posting irrelevant comments to blogs in order to increase the ranking of their site on search engines (especially blog search engines like Technorati and Google Blog Search). 

The folks at Six Apart (makers of Movable Type, Typepad, and LiveJournal) have put in place two possible solutions.  First, post your comment and your email. The comments go in a queue and get posted as I approve them.  Unfortunately, no spam filters yet (though other blogging platforms have them) so if someone did decide to post a significant amount of spam I'd have to delete the comments one by one.  Another possibility is for anyone who wants to post on blogs to get a TypeKey account.  Once you have a TypeKey account, you can use it to post on many blogs and maintain complete control over how your contact information is used.  You can decide not to share your email address at all, share it only with the blog owner (so he or she can respond to your comment privately if needed), or to share it with everyone as part of your TypeKey profile.  Read the site for more info.  Either way, I'd love to hear from everyone reading the site - whether you agree or disagree with me.  Hey, I can take it!  If it gets too bad, I can always go have a lunchable...!

From China? You Can't Read This...

It's been an interesting week for Cool Verification.  This week was the first time I've shared the URL with the folks on the Specman Users Group.  I got a lot of interesting responses and a lot of hits from all over the world.  One place I didn't get any response from was China. It didn't really cross my mind until I got an email from someone who wasn't able to access the link and asked if I could send them the article via email.  Turns out they were trying to access the site from China, which apparently is blocking access to all sites hosted on TypePad.  Too much incendiary rhetoric about the differences between Object Oriented Programming and Aspect Oriented Programming I guess.  If you're from China and are able to access this site, let me know.

Verification Unleashed

Here's a question for all you verification engineers out there.  How many times have you been sitting around, minding your own business, when the project manager appears and says something like "Hey, we've made great progress on our new chip's architecture and micro-architecture, and we've already started coding the design... How long will it take you to verify everything?"  It's not uncommon for designers and architects to ignore the verification team until they well along in the design process.  Then, they complain loudly, wondering why the verification team is spending so much time developing test environments instead of writing tests, or about how all the verification team seems to do is pester them for more documentation.  What if there was another way?  As it turns out, there is, and it has the potential to dramatically improve the quality of first pass silicon.

Continue reading "Verification Unleashed" »

Switching from AOP to OOP - Strategy and Factory Patterns

I started my verification career using Specman.  As such, I have a pretty good understanding of how to design a verification environment using e and Aspect Oriented Programming (AOP) techniques.  Over the last couple of years I've been building my expertise in strictly OOP based environments such as C++, SystemC, and Vera.  It's been a bit of a struggle, as AOP makes rapid prototyping of a test environment a piece of cake (relatively speaking).  The reason is that AOP allows the creation of cross-cutting concerns that can be applied after the fact to allow the user to modify very specific portions of a data structure.

Continue reading "Switching from AOP to OOP - Strategy and Factory Patterns" »

Auto-dependency Generation

I mentioned in a previous post that I've been ramping up Vera over the last few weeks.  So far, so good.  One question I had for some of the other guys at Verilab was whether there was a way to easily generate dependencies for a collection of Vera files to use in a Makefile.  As it turns out, Vera has some tricks (which I have yet to fully explore) to help manage which files should be compiled without the user needing to do much at all.  However, our very own Will Partain provided an interesting solution that has the potential to solve the general problem of generating dependencies for any build environment. 

Continue reading "Auto-dependency Generation" »

Oh Roomba, How I Love Thee

Earlier this spring I came across a news article about a company called iRobot.  iRobot makes the robots used by the US military in places like Afghanistan which look strangely like Number 5 from the 1986 movie Short Circuit. Packbotexplorerright

As it turns out, they also make something  slightly more useful to the average household called the Roomba.  The Roomba is a robotic floor vacuum cleaner which is supposed to relieve the average homemaker of the arduous chore of vacuuming the house.  The price?  A mere $300 for the top of the line model, within the same price range of a regular upright vacuum cleaner.  Could it be true?  Would the thing work as advertised? 

Continue reading "Oh Roomba, How I Love Thee" »