Part of the  

Solid State Technology

  Network

About  |  Contact

Headlines

Headlines

IP interoperability in SoCs: Mix and match doesn’t always work

By Matt Hogan, product marketing manager for Calibre Design Solutions at Mentor Graphics.

Design re-spins, shorter time to market schedules, and the continued productivity pressures on engineers within the integrated circuit (IC) design community have all contributed to the widespread re-use of intellectual property (IP), which is seen as a quick way to incorporate proven technology in a new design. The thing is, more often than not, a design re-spin isn’t just a simple re-spin with a tweak here and a tweak there. The new design will probably have to comply with modified specifications that inevitably raise the bar for performance and power usage, and it will probably contain new IP that must be integrated. At the same time, the design team will be told to leverage as much of the silicon-proven IP already in production as possible. The verification from the previous design must be re-done, using as many automated tools and processes as possible to minimize timelines. With multiple power domains, complex power management schemes, and high signal counts, reliability concerns for today’s low power designs are at the forefront of priorities.

In 2011, the ESD Association published a technical report on ESD Electronic Design Automation Checks (ESD TR18.0-01-11) that outlined a number of recommended reliability checks. Not content to stop there, they continued work on a revised version of this report (publication forthcoming). Contained within this report are a number of recommended cell-level electrostatic discharge (ESD) checks. Rule 6.1.1 is titled, “Verify that Correct Version of the Device/Design Kit/Cell/Library is being used when using Standard Library Cells or Parameterized Cells (PCELLs)”. The focus of this check from the ESD community is to ensure that the cell has been “screened” to ensure it is acceptable for use within the design.

While the ESD focus for checking cell names is valid, there are broader reasons to validate the interoperability of cells being used together within the same design. Most of these focus on controlling and understanding the isolation of power and signals within the design. Imagine, if you will, a SERDES buffer contained in one cell, while supporting circuitry is contained in other cells. If an optimization is made to the SERDES buffer that also requires tweaks to the circuitry in the other cells, we now have a situation where the versions of all of these cells are now interdependent. How do we capture this interdependence in the design? More importantly, how do we control the situation so that other designers using these cells use the correct versions?

Figure 1. Re-spins of production designs may implement new cell versions that affect interoperability.

Figure 1 shows a case where five blocks were used successfully in a previous design. The version numbers of these blocks are proven to be compatible with each other. However, since the production of that design, the libraries containing these cells have been revised, and newer versions of these cells are now available. Unfortunately, simply accepting the latest versions from the design library may not yield optimum results. The new design on the right uses the latest versions of these cells, but who has validated that these new versions are compatible with each other, and with the older versions of the unchanged cells?

Internal design rule manuals provide a central location to store a vast array of different design rules. It would not be too much of a leap to include version numbers of cells and interoperability information. Alas, updating the design rule manual is a manual process, subject to the usual human error and forgetfulness. In addition, even if provided, the information could be easily overlooked, particularly for designs with large numbers of IPs and a significant number of dependent cells. Should you accept the latest version of a cell? Some very desirable optimizations may be implemented with new cell versions, but so, too, may be a dependence on a library cell of which you’re completely unaware.

Design flows, IP library conventions, even project requirements, all point to the need for a flexible solution. IP interoperability is an important but often overlooked aspect of SoC design that can be validated early and often in the design and chip assembly stages of the design. Many CAD groups write their own scripts to try to validate these conditions, but development and maintenance of custom code is time-consuming and costly. An automated method that can evaluate the cells in a design (including version numbers) in conjunction with any interoperability rules that may exist and report conflicts back to the user would seem an obvious choice. Tools such as Calibre® PERC™ are giving designers the power to quickly and effectively validate this reliability aspect of their designs early in the design flow. Final verification of cross-domain issues and other reliability issues can be found with final sign-off decks.

Early identification of potential interoperability issues in your designs helps keep your projects on track in a repeatable and controlled manner. Being aware of the issues is the first step. Adding automated interoperability verification to your design flow to uncover dependencies and resolve interoperability conflicts helps you keep designs on schedule while ensuring the designs take advantage of optimizations that can improve design performance and reliability.

Author:

Matthew Hogan is a Product Marketing Manager for Calibre Design Solutions at Mentor Graphics, with over 15 years of design and field experience. He is actively working with customers who have an interest in Calibre PERC. Matthew is an active member of the ESD Association—involved with the EDA working group, the Symposium technical program committee, and the IEW management committee. Matthew is also a Senior Member of IEEE, and a member of ACM. He holds a B. Eng. from the Royal Melbourne Institute of Technology, and an MBA from Marylhurst University. Matthew can be reached at matthew_hogan@mentor.com.

Tags: , , , , , ,

Leave a Reply