A View from the Top: A Virtual Prototyping Blog

 

Are Hardware and Software Developers Not So Different After All?

I am exposed to embedded software and its testing again a lot lately. An article from Jack Ganssle made me think of the old “United Colors of Benetton” commercial (picture from here). Are software and hardware developers perhaps not so different afterall? BTW, before proceeding, if you are not signed up for Jack’s newsletter “The Embedded Muse”, then I’d highly recommend to do it. It’s a great source of information about the embedded world.

In his article on “The Use of Assertions” he refers to a Microsoft paper called “Assessing the Relationship between Software Assertions and Code Quality: An Empirical Investigation”. The paper nicely outlines that the use of assertions increases code quality and gives empirical proof. I include a graphic from page 10 of the paper below. The example nicely shows a high fault density for code that has zero assertion density and higher assertion density for code with low fault density.

So far so good.

The article also compares dynamic and static tools. There is a graph on page 11 which empirically shows that the bug percentages found dynamically via assertions are actually higher that the bug percentages using static analysis tools. Well, at first I was clinching and wondering – wouldn’t it be great if this could be done all statically? There are different embedded software companies out there focusing on static vs. dynamic testing and it reminds a bit of the hardware world where we find bugs using formal and dynamic verification as well. The immediate conclusion could be: Hey, they are not so different after all those hardware and software verification engineers.

image However. after a great read of Microsoft’s James Larus, et. al, called “Righting Software” and some of the references from the original Microsoft Paper, it turns out there are are fundamental differences as well. In my mind there is always a difference of verifying “form” vs. verifying “function”. Verifying function means to me to make sure that code is doing what it is supposed to do, “wait until the USB connection is established and then start some other functions”. Verifying form means to me to make sure that the function is expressed the right way and correctly, i.e. all memory allocated used to do a task is indeed freed at the end, all internal and external coding guidelines are met.

It seems to me that dynamic assertions are used in both worlds to make sure function and form is met. I can make sure with an assertion that a specific state is hit – or never hit – as well as indicating that at the of a major process not all memory has been released, or semaphores have been executed in the wrong order, which may result in a risk of locks in a multicore system.

Static verification – at least the ones I encountered – is in the hardware world mostly used to verify function. Certain states have to be hit or are never allowed to become true. Given that there are so many the “state explosion” has always been an issue on the hardware side. From what I can tell the static verification tools in the software world seem to be focused on verification of form mostly. Hence I have not seen any issues around state explosion in the software world.

Some differences, some similarities. Perhaps assertions can be a bridge between HW and SW verification as my colleague Tom Borgstrom (read his Blog “On Verification” here) put it in a discussion recently. Or I may be completely wrong on all this … so I am looking forward to your comments!

Share and Enjoy:
  • del.icio.us
  • Digg
  • Facebook
  • Google Bookmarks
  • Print
  • Twitter
  • StumbleUpon
  • LinkedIn
  • RSS