Hierarchy Applied to Semiconductor IP Reuse

When I first started doing IC design back in 1978 we had hierarchical designs, and that was doing a relatively simple 16Kb DRAM chip with only 32,000 transistors using 6um (aka 6,000 nm) design rules. SoC designs today make massive use of hierarchy at all levels of IC design: IC Layout, transistor netlist, gate level netlist, RTL level, C or SystemC level, embedded software, software drivers, firmware. Our semiconductor IC business is based on both IP and EDA tools being able to handle hierarchy effectively.

One company in the EDA space that knows quite a bit about IP reuse is Methodics, because they’ve built a company that focuses on IP use and reuse. Their latest generation IP management system is a software tool called Percipient that enables IP reuse for a wide range of IC design teams where a user and manage their IP as a collection of dependent, hierarchical building blocks, then reuse entire hierarchies instead of single IP blocks.

The methodology in using Percipient is that everything in the design hierarchy is treated as IP, starting at the top-level of the SoC, down to a module, a block, even a cell like a PLL. So your project in Percipient can be at any level of hierarchical description, enabling elegant reuse. In the following diagram we can see a USB Controller that has a regular resource of a USB PHY cell along with a private resource of a USB TestBench:

The USB TestBench is a private resource that makes sense to use when the USB controller is used in a standalone context, but not while actually using the IP as part of a larger design. At the top-level of my SoC I don’t really need to carry around this private resource of a USB TestBench. As I place this USB Controller into an IO Subsystem the private resources are noted, and these private resources are visible only to a certain level of the IP, but not the parent IP.

The IO TestBench is relevant to the IO Subsystem only, but as I place this IO Subsystem into my SoC as another IP block then I don’t need to see or deal with the lower-level private resources any longer. So I can use this IO Subsystem multiple times on different projects and not be concerned with the private resources associated with it.

So, what do we get with a context-dependent resource (aka Private Resource)?

• Manage peripheral resources (stimulus generators, testbenches, PDKs, etc) as IPs in my system for tracking, releases, or caching.
• Reuse any IP easily in a variety of contexts while not having to make any context-specific changes.
• Customize my development environment of IP blocks while not interfering with private resources in their separate context.

Hierarchy is a wonderful thing and is commonly used within EDA tool flows, so its refreshing to know that Methodics has figured out how to support hierarchy as part of the larger IP management task by supporting the concept of private resources, allowing us to manage these private resources along with all of our other IP. At the top-level of my SoC I can see just the IP blocks that I need to manage my project, and I don’t need to be bothered with lower-level IP blocks that only pertain to a different context. With Percipient I just see what I need to at each level of the hierarchy.

White Paper
To get more insight into this topic then read the four page White Paper at the Methodics web site here.

Related Blogs

• Rethinking IP Lifecycle Management
• Something new in IP Lifecycle Management
• New Concepts in Semiconductor IP Lifecycle Management
• Achieving Requirements Traceability from Concept through Design and Test
• CTO Interview: Peter Theunis of Methodics

ISO 26262 for Semiconductors
The attractive automotive market has some unique safety requirements that are defined in the ISO 26262 standard. To learn more about how design data and IP lifecycle management fits into the ISO 26262 standard then consider attending the roundtable discussion led by Methodics at the December 6th event in Munich, Germany.