By Dean ~ January 22nd, 2009. Filed under: Industry.
Paul brought an interesting article to my attention this morning. Qualcomm‘s Saranyan Vigraham, published a “Viewpoint” piece up on Embedded.com, titled “Competitive Advantage vs. Collaborative Advantage.” Mr. Vigraham acknowledges that today’s commercial EDA tools are not sufficient to complete design tasks. This forces semiconductor companies to augment the tools with in-house software engineering projects.
“… every company builds custom tools to support their flow. Most of these tools either involve extending the existing EDA tool functionality or developing a framework for increasing the efficiency of the design or verification process. However, these neat little tools or ideas never come out. They are seldom published or advertised because every company believes that they lose a competitive advantage by disclosing these ideas.”
Through the rest of the article, Mr. Vigraham proposes a process for companies to evaluate which internal extensions they might want to share, and which ones make more sense to keep proprietary. The discussion is well thought out, and certainly bears consideration. Recent comments on open source notwithstanding, I think that we are moving into an era where increasingly significant components of the semiconductor designer’s toolset come from non-proprietary sources. We’re keeping a close eye on the developments within the Eclipse Foundation, for example.
As a tool vendor, however, I do anticipate some potential issues with Mr. Vigraham’s suggestion. First, many internal tools are designed to do a specific task well. They may not be generally applicable, and they may not be as forgiving of unexpected inputs as commercial tools must be. Of course, I don’t want to imply that the tools are hacks, but we’ve all seen some less than “best practice” coding in internal tools. Second, grass roots efforts like this often need some sort of organizing entity to get off the ground and to provide some sort of structure. At least they would seem to need some organization to provide a primary site for accessing the shared tools. Finally, companies would have to scrub their contributions carefully to make sure that the code thrown into the public bin didn’t reveal any proprietary information regarding IP, non-shared tools, or vendor confidential interfaces. None of these are showstoppers, but they would require some attention.
I suspect that we’ll hear more about this effort, or ones like it.