You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • Optimizing Return from your IP Portfolio

    Given that SoC design today is predicated on IP reuse, you would assume that processes to deliver, maintain and communicate status on reusable IP should be highly optimized. But thatís not necessarily the case, especially when so many design companies have consolidated, each brings its own IP libraries, design flows, license agreements and inevitably fragmented tribal knowledge about what works well, what doesnít and under what circumstances.

    This isnít a hypothetical problem, Recently, a design group in the Asia arm of a design company purchased an interface IP for $750k; shortly after, the US branch of the same company purchased the same IP, also for $750k. Were they able to sort this out? I donít know but buyers have responsibilities as much as sellers. If too much time passed, Iím guessing the vendor would feel completely justified in pushing back against requests for a refund (try getting a refund from Amazon or Expedia after a few weeks, based on a mistake you made).

    Cases like that are eye-catching but I suspect the bigger losses are in more mundane areas. An important part of the value in an M&A is anticipated efficiencies and new markets opened thanks to sharing a larger pool of high-value IP. And yet I donít think Iím alone in noticing that years after some completed mergers, more than a few design organizations are still struggling to broadly realize these supposed benefits. They certainly gained market share; efficiencies around IP are sometimes less clear. When sharing between organizations proves ineffective or inefficient, teams reinvent the wheel constantly, or spend more time adapting IP they thought would be drop-in, or they simply fail to exploit opportunities that should have delivered significant market advantage.

    Some of the problem starts with the way we view IP, as an essentially static end-product of IP development. Of course you hope the functionality changes less frequently than circuitry unique to the current design, but there can be a lot more information about an IP, changing more frequently than the functionality Ė bugs filed and status, schedule for bug fixes, silicon experiences and measurements and who else is using and has used this IP and in what configurations. All of this is very dynamic information, critically important to any current user. And it all evolves as new releases appear and new information flows in. Another design went into a respin because of a problem on that same IP? I might want to know that. Or Iím depending on a critical fix, but that need wasnít passed down to the IP developers or status wasnít rolled back up to those who might need it. I might want to know that too.

    A Consensia-sponsored survey of design teamsí problems with IP highlights these issues: #1 they spend too long looking for the exact IP they need (incomplete databases, inadequate documentation, Ö), #2 they donít know if they are allowed to use the IP on their design (license issues, ITAR issues, discontinued support, Ö), #3 they didnít know the IP they wanted was already available (so they built their own) and #4 they didnít have a good measure of the quality of the IP (yeah it exists, but nobody has used it, or it has a history of working well in certain applications but not in your application).

    None of this will be a surprise to any experienced design organization. Each has typically built up home-brewed flows to address at least some of these needs, based on different DDM, bug/defect tracking, release/testing frameworks and possibly some kind of lifecycle tracking. Which is great, but thereís no easy way to bring different flows together in a merger (which may be why many are still struggling years after the M&A). Brute-force consolidation is frequently impractical. This problem becomes even more challenging when you are working collaboratively on a design with a customer.

    Consensia offers the DelphIP platform to address all these problems, at the enterprise level where it can benefit all business lines in an organization. This provides a common and centralized way to track status, history, restrictions, maturity/quality along with other characteristics that arenít commonly represented in EDA/DDM/defect tracking views. It also sits on top of and communicates with existing DDM platforms, bridging between existing local flows and enterprise-level IP communication and management.

    DelphIP also supports collaborative workspaces so you work effectively with a customer in support of their value-adds, without having to expose all the gory (and proprietary) details that go into producing a modern design. Which is something you may be required to consider if you are working in the automotive space, to name just one example. You can watch the Consensia webinar on DelpIP HERE.