IP Issues At 10/7nm

For years chip makers have been demanding more options to assist them in getting silicon to market faster. As of 2018, there are now so many possibilities for chip makers that engineering teams of all types are having trouble wading through all the possibilities. To make matters worse, many of today’s choices now come with unexpected and often unwanted caveats.

At the most advanced nodes, it’s a given that being able to shrink features and double pattern with colors is no guarantee that everything will work as planned. But at the most advanced nodes—10nm and 7nm—complexity is now overwhelming development schedules to the point where process technology, materials and design rules may be in flux right up until tape-out—or worse, after tape-out.
Things aren’t necessarily better at established nodes, either. There are multiple new process variations being introduced at older nodes because of the need to reduce power or add granularity into power/performance tradeoffs at those nodes to preserve battery life.

IPs may not be fully characterized or even available on some of these older processes, or on similar processes at competing foundries. For IP vendors, choosing which processes to support, from what foundry and at what nodes is an expensive guessing game. Not all of them are in sync at all nodes.

For a system company this provides a different situation altogether. Even at established nodes, new variations of processes can affect IP performance and interactions with other IP’s. Even with the same foundry, designers don’t know until they are finished evaluating a process how much effort it will be to re-characterize the IP. Tests need to be completed on new process files, and there is no guarantee that the process depended on for the IP to work is even closely related to the previous version. If you upgrade the process, even with the same library, you have to re-characterize it.

For a company with a lot of IPs, it becomes a daunting task to catalog the various IPs. Not only do they have to catalog keeping the foundries and the various processes in perspective, but they also need to keep track of the numerous configurations of the IPs and the relationships between the IPs. A mechanism needs to exist to keep track and update automatically. If a new update for an IP is available, then the users of the IP need to receive notifications informing them. Similarly, how does an enterprise decide which processes to use for the next version of the IP? Taking this into consideration, then the mechanism should also have the ability for users to make requisitions for IPs on different processes. This would allow the IP team to look at the various requests and then decide the process node.

With all these complexities, it becomes necessary to have a mechanism that has a front for an IP catalog which can hide the complexities of the selection but provide a configurable browser by which designers can shortlist their IPs quickly. This mechanism for cataloging should be capable of presenting the IPs in different views—categories, process nodes, etc.—making it user friendly to easily search for the IPs.

For more information on categorizing IP, visit https://www.cliosoft.com/designhub.php. You just might have found the mechanism for your next design.