Rethinking IP Lifecycle Management

We recently saw both Apple and Samsung introduce new smart phones, and realize that the annual race to introduce sophisticated devices that are attractive and differentiated is highly competitive. If either of these companies misses a market window then fortunes can quickly change. SoCs with billions of transistors like smart phone processors make semiconductor IP re-use a central approach in design productivity, instead of starting from scratch for each new generation.

Tracking and managing hundreds of IP blocks in an SoC is a task best suited for an optimized tool, not using an Excel spreadsheet and manual email notifications. I’ve written before about Methodics and how their IP Lifecycle Management (IPLM) approach in the Percipient tool is such an optimized tool for IP-centric design flows. One aspect of Percipient that is worthy of attention is their Graph Database (white paper here) which is the key technology for fast and seamless IP reuse.

My first introduction to Relational Database Management Systems (RDBMS) was in the 1990’s while learning MySQL and PHP in building custom, data-driven web sites. Oracle now owns MySQL and it powers many web sites today, like WordPress sites with some 150,000,000 users. Tables are used in MySQL to store rows of information, where each row has multiple columns and some index field. Tables can be related to each other by joining them which enable complex queries.

Percipient instead uses a Graph Database which stores data using nodes and relationships, with key-value properties. A relationship will connect two nodes to one another, and they are both typed and directed. The beauty of this graph database approach is that the relationships can be traveled in either direction. SoCs use hierarchy to define how IP is placed, and a graph database models hierarchy natively.

In contrast, a RDBMS doesn’t natively support or use hierarchy at all. Sure, you could use a series of MySQL database tables to store and traverse all of your IP but the performance would begin to suffer as the data scales up in size.

Related blog – Something new in IP Lifecycle Management

Each IP block in your system has dependencies, so for example a USB component depends on PDKs, libraries and test-benches. Our IPLM has to understand and track all of these dependencies efficiently. Your system may even use different versions of the same component in the same design, so knowing how to avoid conflicts is essential. Dependencies map directly into a graph database, so it’s straight forward to add, delete or manage conflicts. The Percipient tool is used on SoC hierarchies that use several hundred nodes, even up to 8 levels of hierarchy.

The team at Methodics chose the Neo4j graph database in their Percipient tool because of its popularity, speed and scalability. The previous generation IPLM tool from Methodics was called ProjectIC and it used SQL tables with PostGres, which worked fine for smaller designs but didn’t scale up with enough speed. Let’s take a quick look at speed comparisons between the older ProjectIC approach and the newest Percipient through the following scatter plot showing response time on the Y-axis in seconds versus calendar time on the X-axis:

Notice the general increase in time to manage IP as the hierarchy grew to six levels and about 290 nodes while using the older ProjectIC tool, then the customer started using Percipient with a graph database which dramatically lowered their response times and continued to scale well. Actual customer usage created this graph while doing a production IC, not a benchmark. Using the graph database approach the customer can now query the status of a hierarchical IP in a workspace, or even view conflicts in just seconds instead of minutes. These speed improvements will scale into hundreds, thousands or millions of nodes.

Related blog – New concepts in semiconductor IP lifecycle management

Summary

Methodics has been offering their ProjectIC IPLM tool for many years, then took the next step and re-engineered their approach to exploit a graph database in their newest Percipient IPLM tool. The speed improvements and scalability with the Neo4j graph database look excellent, which means that SoC designers save time and are more likely to meet critical deadlines.