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.Share this post via: