In my last blog, Harrison Beasley shared his views on stale IP. This week we hear from Manoj Bhatnagar, Senior Director, Field Delivery and Support at Atrenta.
Liz: Manoj, what is stale IP?
Manoj: An IP may become stale because either its specifications have changed (e.g., USB 1.0 vs. 2.0 vs. 3.0) or there is a better implementation available (e.g., a graphics core is now running at 800Mhz instead of 500Mhz). Typically, people will use the latest version, and the older versions are no longer used. So the stale IPs in this case will die a natural death. What is more challenging, however, is a specific IP developed for a specific project and, over time, no other project used it. So the IP becomes stale. Most of my answers will apply to this type of stale IP.
Liz: What’s so bad about it?
Manoj: The main issue with a stale IP is the fact that nobody really knows the details about it. If I were to use that IP, I would be putting my design at risk because I am now adding some logic to my design for which I don’t have all the information and can’t find anyone who can provide that information either.
Liz: How do we prevent it from being stale?
Manoj: One of the key things that can be done to prevent IP from going stale is to document the IP. I don’t know how many people still remember the TTL datasheets but when you looked at the datasheet, you got complete visibility into what that component did. The same concept can be applied to present day IPs, where you document various characteristics of the IP. For a hard IP, this may be the timing characteristics, physical profile, etc. while for a soft IP this may be timing constraints, clock domain information, testability profile and power profile.
