print

What Do IP Management Systems Need?

SoC designers are a strange, cautious breed of engineers. The fear of failure makes them averse to taking any risks; they will constantly burn the midnight oil, meticulously designing and verifying the SoC to ascertain that it will work the first time in silicon. With such caution and focus also comes a natural aversion to change. Any changes in design methodology are met with resistance as design teams balance the consequences of change and the prospect of a potential failure that the changes may bring. The notion of using an IP developed by someone else within the company makes the defense shield come up and design engineers usually find several reasons against using someone else’s design. Besides, for an engineer, one wrong decision on his/her part would result in the designer facing the ire of the management team. With such dire consequences, why would anyone rock the boat?

But some changes are gradually coming to be accepted, with time. In the 25 years I have been associated with the semiconductor industry, all of us have talked about the need for design reuse as a vehicle to quickly design new SoCs. And the use of IPs has grown considerably in the past decade to become an accepted norm in the design industry. EDA vendors have developed tools for validating IP quality and connecting IPs easily. Semiconductor companies, as well, have developed their own methodologies or internal tools for reusing IPs. While these various tools have enabled the design engineer to make a better decision on whether to use an IP designed by someone else or to develop his own version of the design, they are still inherent risks in using these IPs. How does the design engineer ascertain the open issues related to the IP, or the lineage of the IP? How does the designer contact prior users of the IP and get an update on their experience in using the IP? Who does he contact in the event he encounters problems with the IP?  In the case of third-party IPs, unlike internally developed IPs, most of these issues do not exist. IP providers, driven by their motivation to survive, have learnt to emphasize IP quality and support.

For an enterprise, it is in their interest to use as much validated IP as possible in an SoC as it would help reduce the cost and development time.  If one were to follow the mantra of using as much validated IP as possible, then any (or most) newly-created designs should be made reusable as well. Making any design reusable requires more work, and for a design engineer driven by tight schedules, there is little motivation to design for reusability unless there is a mandate from management.

From a company perspective, design management teams are faced with a different kind of challenge. Despite the emphasis on IP reuse, making designs reusable within the company has proved to be rather elusive. For IPs that have been developed by design teams at various geographically-dispersed locations, what ensures that they are utilized efficiently by all? How does one move beyond business units and geographical boundaries and put into motion a process to produce new IPs, enable design teams to shop around easily for IPs within the company, and move the IPs with ease into their designs. Meeting this challenge has multifold advantages, some of which are shorter project schedules, lower design costs, improved productivity and collaboration within the company, and efficient usage of resources.

To address some of these concerns, engineers conceived the notion of a web-based catalog that would list the available IPs within the company, enabling design teams to leverage them while developing their SOCs. But the solution has not been as successful as anticipated. Was it because companies were so focused on delivery timelines that they were unable to motivate their engineering teams to create reusable IPs? Was it because some business units within an enterprise were less inclined to share their IPs with other groups? Or was it the fear of not knowing the issues associated with the IPs listed? Another roadblock may have been that some companies had their own unique workflows, which required authorizations for downloads.

At ClioSoft, where we serve the analog, mixed-signal, RF and digital design markets, we have been perplexed by the same problem. While our IP management solution, built into our SOS data management platform, is being used at a number of companies, we keep hearing woeful tales about IP reuse from both engineers and managers. So, a few months ago, we conducted a survey where we asked working engineers and engineering management to write about what they think should be done to improve design reuse within an enterprise. What are the key features any IP management system (for lack of a better name, let us continue to refer to it for now as an IP management tool) should have to meet the requirements for IP reuse needed for tomorrow’s SoCs? To incentivize designers and managers to provide their input, we offered some attractive prizes to survey respondents. We received about 100 useful responses, which provided an interesting perspective. Engineers aren’t usually inclined to provide anecdotal answers to questions, but we were pleasantly surprised at the number of lengthy responses. All the answers were write-ins and we got varying points of views from the analog, digital and RF design community. One of the places where we solicited responses was on John Cooley’s DeepChip website, and he published a few results verbatim.

Categorizing all responses ourselves, we found the following common needs:

  • Need for a commitment from the top management to IP reuse. The fact that about 13% of respondents mentioned this as still necessary surprised us somewhat. The big semiconductor design houses have been talking about this for a decade, but, despite the increased use of IP in today’s chip and SoC designs, evidently many companies do not have a company-wide management drive to make reuse a design priority. As one of the responders mentioned “If designers are not supported by their technical management to create IP, a reuse culture will gain no traction. Designers must be afforded the extra time required to build IP infrastructure into their blocks or it simply will not happen. Technical management needs to account for additional time in development schedules to make this a reality.”
  • Better communication with IP teams on various issues such as support, performance, architecture. As one respondent mentioned “Another aspect necessary for re-use, is the ability to discuss / share ideas and information about the content so that people can learn more about how designers have used or are planning to use the IP, and what issues or questions were already discussed and answered regarding the IP.”
  • List of SoCs the IP has been taped out with
  • Ability to compare IP variants. As one of the engineers mentioned “While selecting an IP, there should an easy way to determine its suitability and quality. If there are different versions of the same IP, one should be able to easily compare the IPs and determine the version, which is most suitable. Designers should also be able to quickly run the scripts to determine the quality of the IP.”
  • Need for good documentation on the IP
  • Need to ensure that all IPs are validated before being uploaded into the IP repository. IPs must be accompanied with scripts so that designers can quickly validate them prior to use
  • Integration with a revision control system
  • Ability to review/track open issues for an IP
  • Need for a flexible platform for implementing easy to use methodologies aimed at improving design reuse
  • Systems that can handle worldwide or multisite design teams

In the course of their answers, most design engineers mentioned that proven IP would save them time, since they would benefit from the time already spent discovering and fixing issues. In other words, a way to determine the SoCs that the IP has been taped out with would tremendously boost confidence in the IP. Due to some of the problems mentioned above, “small, simple and standard interface IP is in greatest use,” as one engineer put it. “People are willing to use USB and other simple IP. More complex IP often requires more investigation and trust, and it can take more time to develop the trust than to design the IP yourself.” Or as another respondent said, “Every time a designer has to make an effort to solve something that an IP reuse management system does not do for him, he has discovered a reason not to use the system at all.”

For the overworked engineer, it is paramount to have a platform where the designers of SoCs and IP sub-systems can share IPs and communicate with IP developers. To make design reuse work, the platform must address the abovementioned concerns, so that designers can develop and upload IP and management and design teams can shop/compare IPs and consume them seamlessly.

About the Author:

Ranjit Adhikary, director of marketing at ClioSoft Inc., has 15 years experience in EDA engineering and technical and product marketing.

Contact Information

ClioSoft Inc.

39500 Stevenson Place
Suite 110
Fremont, CA, USA
94539

tele: 1-408-496-5890
fax: 1-408-496-5890
info@cliosoft.com
www.cliosoft.com

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis