An Update on IP Lifecycle Management (IPLM)

IPLM is not always prominent, nevertheless it is a very necessary aspect of semiconductor (and systems) design. Modern designs build on a wide range of IPs and subsystems, each evolving through multiple variants and versions, each with different PPA characteristics and recommended use-cases, many from different suppliers and/or in different states of readiness, or possibly no longer supported. Then there are license agreements and export restrictions. Managing this complexity is not a task that can be left to a spreadsheet. IP catalog management demands high levels of automation all the way from product design to in-field support and ultimately through to decommissioning.

The essentials of IPLM

It is very rare that a full system design starts from scratch. Most designs build on significant legacy system and subsystem data, refining and evolving to meet new and more challenging objectives. Inevitably IPs used in those legacy systems may been upgraded. Should you continue to use an old version or switch to a newer version? You may not have a choice if the old version has been deprecated. Or maybe you need the newer version of performance characteristics, but the older version is proven in silicon where the newer version may not yet have that advantage.

In bringing legacy subsystems together you may find they use different versions of the same IP, for whatever reason. In a combined system to be fabricated in one process that conflict must be resolved to one selection. Your decision of course on how you want to resolve such a conflict, but first you need to know where the conflicts are.

There is a different spin on this issue in chiplet-based systems. Each chiplet provider will drive manufacturing according to their IP choices which need not affect manufacturing choices for other chiplet makers. Here IPLM must recognize that conflicts between chiplets, unlike conflicts with a chiplet, need not be limiting.

Traceability is an important consideration throughout a design lifecycle for multiple reasons. Problems detected in other designs can be flagged to other design teams or to customers, with proposed workaround. Some standards such as ISO 26262 require detailed traceability. License agreements demand that usage be tracked. Further, export restrictions can be quite dynamic these days. You can’t recall product already in the field, but you need to know what might require a redesign, to become compliant with a changed restriction.

AI and IPLM

As a favorite topic of mine naturally I am interested in how IPLM integrates with AI, especially in agentic flows. I recently listed to a Perforce webinar, on enhancements to their product touching on some of the topics above and particularly on their directions in AI. These include an MCP interface to the underlying Perforce technology, which I imagine should enable direct connection to agentic flows. They also mention a RAG server to help IPLM novices learn how to use the system, for example how to set access controls. The intention is to expose this capability through a chat interface. I am told that planned release for these capabilities is June 2026.

Interesting stuff. Managing IP usage across an incredibly complex matrix of characteristics and restriction has become very challenging task. Adding agentic methods into the mix will further simplify understanding, search and management in SoC and multi-chiplet designs. Again you can access the webinar HERE.

Also Read:

IPLM: Future Forward Webinar May 19th

Perforce and Siemens Collaborate on 3DIC Design at the Chiplet Summit

2026 Outlook with Kamal Khan of Perforce