Archive for November, 2009

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.

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!

Earlier this week I attended an ICCAD co-located session on the future of EDA. Jim Hogan and Paul McLellan led an interesting discussion on what has to change to make a chip development successful in 2012. A lot of the early feedback in the Blogosphere on EDA seems to be right akin to the movie scripts like in Doomsday or the upcoming 2012. Are we at five minutes to twelve on the doomsday clock (the is picture borrowed from here)? I would argue that EDA always has been part of a complex changing landscape and has been able to solve the challenges. Will we again? Sure, I know a lot of people working on it daily!

The slides of the presentation Paul and Jim used showed some interesting data, including a graph on adoption of technologies on page 5. The iPhone and iTouch are the fastest adopted consumer devices ever, beating the iPod itself and the internet. Software is key to that success. Paul also pointed out that semiconductor economics determines a lot of issues in our industry. As a result of cost shifting to software, Paul and Jim articulated the requirement of a software sign-off.

If you have read any of my Blog entries before, then you know that I wholeheartedly agree with the importance of software. I also fully agree with the direction we need to take to enable software development and as early as possible hardware/software integration. The key is timing. I know exactly what my Dad would say in this situation. He would quote the old German saying that “nothing is consumed as hot as it is cooked”. Don’t take me wrong – I do not want to downplay the importance of change. The questions are when, how and where. On “when” – we certainly have been trying for a while to get to the next level of abstraction. With transaction based design we are making progress I am part of teams who are working on the “how” every day in our world of system-level design, virtual platforms for early software development an so on. On “where” it is very clear to me that change is not EDA specific, it happens everywhere in the semiconductor related eco-system.

The adoption curve of page 5 of Jim’s and Paul’s presentation made me choose the title of the Blog. One key differentiator in the development of Apple’s iPhone and the iTouch is “control”. The design of the hardware and the software is controlled by the same company. The situation is different for phones using Windows Mobile, Symbian or Android. Here the OS and hardware are controlled by different vendors. The OS effectively locks in the channel to access the hardware and provides the necessary monetization – providers take a share of every application sold through that channel. The idea is great and if a vendor has control of both he can flexibly allocate the monetization between hardware and software.

System-level design may turn out to be about control and about enabling communication to assert it. One of the beauty of system-level models – of functional algorithms and of architectural platforms running software – is that they allow effective interaction between companies or between groups within companies early on in the design flow. In exchange that communication enables better control of requirements. For example architects can change the hardware to address issues the software brought up. And eventually we may arrive as suggested by the ICCAD discussion at a “software signoff”. Will EDA help get us there as part of a constantly changing ecosystem? Time will tell. We are definitely working on it daily! My boss is knocking … back to work