Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

Exploring innovations in hardware debug

Posted: 19 Jul 2012 ?? ?Print Version ?Bookmark and Share

Keywords:ASIC? ARM? Test-driven development?

Debug represents a significant cost to hardware development organizations and a constant source of frustration for engineers. According to a survey commissioned by Mentor Graphics in 2010, verification engineers spend an estimated 32% of their time debugging code[1]. In a typical 8-hour day, that translates to more than 2.5 hours specifically dedicated to fixing defects.

Spending 2.5 hours debugging code can make for a frustrating day for an engineer, but what does that mean for the organization? According to the EE Times Global Salary and Opinion Survey from 2010, the annual compensation for a North American engineer, including bonuses and overtime pay, averaged $107,300[2]. From that, it's easy to make a best case, back-of-the-napkin estimate capturing the cost of employing a medium sized team of engineers to build a reasonably sized ASIC. The result is a very big number.

Now take your napkin to the CEO and tell him that 32% of the employee compensation he pays out for developing a next generation ASICroughly $1 millionis going to be flushed away fixing defects that the team itself injects by writing buggy code.

That's a make-work project no CEO is going to want to pay for, yet assuming the results of the 2010 Mentor Graphics study are accurate, most of them are already doing it.

Spending 32% of an engineer's time fixing defects is unacceptable by any standard in any industry, which is why EDA companies and engineers alike have been searching for ways to expedite debug. Isolate bugs faster, fix bugs faster; two worthy goals with huge potential payoffs. But is this kind of reactive problem solving the right way to address an activity that consumes almost a 3rd of an engineer's day? Or does the amount of time we spend debugging code suggest a fundamental flaw in the way we go about designing hardware and writing code?

Bug prevention with test-driven devt
In his day 2 keynote talk at DAC 2012 in San Francisco, Mike Muller, CTO at ARM, drew from his years of experience to make several interesting comparisons between generations of ARM cores and the practices used to design them. At one point in his talk, Mike wonders aloud "have designers got lazy?" when presenting data suggesting the Cortex-M0 was developed with 1/3,000,000th the engineering efficiency realized during the development of the ARM1[3]. Mike continues by suggesting an air of complacency in hardware development where very little innovation has taken place since moving on from the hand placement of transistors. When describing a "desperate validation challenge", he says to find bugs "we do all of things we always used to do".

In comparison, software developers, he suggests, "they've all moved on. They use frameworks, new languages; their programming paradigms are completely different... Most of the industry has moved on". Interestingly, Agile development is first on his list of examples of how software developers have moved on.

Instead of continuing to foster an environment of complacency and reactive problem solvingor debuggingin hardware development, a proactive step toward eliminating the costs associated with defects would be to adopt design techniques that produce fewer defects. Test-driven development (TDD) is one such technique.

1???2???3?Next Page?Last Page



Article Comments - Exploring innovations in hardware de...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top