Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Innovation woes: Why must we always blame others?

Posted: 15 Oct 2015     Print Version  Bookmark and Share

Keywords:software  hardware  semiconductor industry  physical design  debug 

Someone's always blaming someone when a thing or two go wrong. This situation is not unique to politics and governance. Even in the world of electronics, such a thing normally occurs.

We're always hearing that innovation is a team sport. Nowhere is this more the case than in today's semiconductor industry. Different teams and skill sets are required to architect the system, generate the RTL, perform place and route, implement the physical design, verify and debug both the logical and physical design, and generate the software that runs on a typical core-based SoC.

You might think that in this environment, people would be used to taking collective responsibility for taping out a chip on time and to budget, so why is it that one of the most commonly heard mantras in our industry is "It's not our problem"?

This is particularly true when it comes to the hardware/software teams. Anyone who's worked in our industry for any length of time will have listened to the hardware guys blaming a software problem, only to cross the room and find that the software guys are convinced that "the problem's in the hardware." But even within the "community" of hardware designers, there's a tendency to blame another team.

Part of the reason for this is inertia. People get used to working in silos and doing things in a certain way. But "the most dangerous phrase in the language is—we've always done it this way" (a phrase attributed, appropriately enough, to Rear Admiral Grace Hopper, who is also credited with inventing the term debugging).

Today, more than ever, we need to embrace a holistic approach to chip development. Technologically, an important part of this is to design into every chip structures that help us understand exactly how the final device operates: including the complex interactions between hardware blocks, often sourced from different third parties, and the relationship between hardware and software.

The existing tools for this are inadequate—we often rely on JTAG, a technology that is 30 years old. But because we have the excuses that "it's somebody else's problem" and "we've always done it this way," the impetus to adopt a better approach is not there.

1 • 2 Next Page Last Page

Comment on "Innovation woes: Why must we always ..."
*  You can enter [0] more charecters.
*Verify code:


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


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top