With the steady advancement of manufacturing process geometries enabling new levels of integration on a single chip, the use of IP – whether internally developed or sourced from a third-party – has become more complex. Such complexity is inherent in any type of process where more elements are introduced (i.e. IP blocks), and is compounded by factors such as geographically diverse design teams, a lack of standard metrics for IP use and quality, and shifting design parameters. A modern SoC development project has a plethora of "moving parts." While there are many tools available to help verify, debug and otherwise manipulate IP, there has been a distinct lack of a solid design data management system to address the specific needs of SoC designers in this type of dynamic environments.
As a result, IP use in general often suffers from a bad rap in terms of quality. The term IP quality has different meanings to different people, but in general terms it refers to 1) the functional correctness of the IP – does it work they way it is supposed to (i.e. bug free)"; and 2) does it do what I need it to do with respect to my design parameters – power, timing, area, etc.? Developing and integrating quality IP by either or both of those definitions requires a system that can effectively track changes and input across the entire design team at the desktop level, provide real-time access to a wide range of meta data and quality information on IP, as well as keep project managers and other senior management informed on how the use of IP is impacting schedules, budgets and design resources. Without accurate and current quality metrics for dependent IP components designers are often forced to overdesign using pessimistic slack definitions, unrealistic size information, inaccurate power estimates etc. A system cognizant of the IP versions in a users current context, with up to date metrics for dependent blocks provides a truly collaborative and accurate development environment, which translates to reduced development cycles and cost, IP management in the old days
In the past, designers used relatively simplistic RCS/CVS file versioning to manage changes in designs. Over the years next generation DM (data management) tools emerged which improved performance and reliability. These tools added a layer of abstraction over the file versioning problem. As designs became more complex and design teams diversified, it became common to have multiple DM repositories and even multiple DM tools used on a single project. Today, many design organizations struggle to keep project-data organized properly and communicate changes effectively. Finally, exacerbating the situation, companies suffer from poor or no permission management strategy, bad performance, inconsistent data management systems and spiraling disk/network resource requirements. There has been no single way to control, measure or manage the situation.
Companies have addressed this problem through proprietary solutions or have tried to integrate enterprise PLM (project life-cycle management) systems. But both of these approaches are time-consuming and distracting for an organizations which needs to be focused on IC design, not project management systems. And neither provides a complete way to address the specific needs of a complex SOC project.
What is needed is a way to improve the design environment from the designers and integrators perspective while providing concise management tools for the project manager: a top-down solution that promotes designer best practices, and provides a collaborative platform for the next generation of IP management solutions.
Addressing IP quality through effective SoC design data management
Let's look at the two levels of IP quality I mentioned above.
First, bug tracking. Most ticketing systems used today by Verilog and VHDL users were originally developed for software developers not hardware designers. In software when you find a bug you fix it in the current release, backport it to previous releases that you care about and close the bug. This means that bugs can be managed at the project level, and there's no need to worry about which releases have a bug is present in or not,
In an SoC, bugs must be tracked at the IP version level since SoCs are defined by a BOM that assembles a collection of IP versions. Backporting the fix to a previous release is a lot more complicated and typically isn't done at all. The presumed expectation is that the fixed version of the IP (variant) will be used in subsequent release of the SoC only. This means that bugs must include "Effected Version" information to track which SoCs are impacted by a particular bug.
A more effective approach is to show the user a current list of active issues on that IP and give him the option to close one or all of them – each time and IP release is created. If a bug is closed the new IP version is not included in the list of effected versions for that bug, the bug does not get actually closed since it is still open on previous versions.
Another important aspect of IP quality is ensuring the right IP is being used for a specific design requirement. This begins with designers having access to a database that tracks all IP under development in the company including what IP and version are being used per project. This is essentially a map of the IP "fabric" across the company. Designers could then annotate properties on IP versions in the database by using "agents" that are configured to report back important IP quality metrics that come from power simulations, static timing simulations, test coverage runs etc. Once these quality metrics have been overlaid on each IP version in the catalog, they can become available to Verilog/VHDL designers as part their development environment. When a user is working on a Verilog module they can query the database from their Unix shell for the latest metrics on that module or other connected modules to help identify what aspect of the design needs to be worked on. Timing/power "slack" can be updated in real time and made available to individual designers to identify their design goals accurately.
These are just two examples of how a SoC-oriented design data management system can dramatically improve IP quality. Of course such a system must be easily integrated within the existing design flow and be non-disruptive to designers. But improvements in the way designers can access IP information "on-the-fly" and use it to ensure they are utilizing functionally-correct and design-appropriate IP will pay huge dividends. If implemented correctly, a robust DM solution not only ensures higher levels of IP quality, but will result in significant improvements in designer productivity, development costs, and time to market.
Simon Butler is the CEO of Methodics LLC, is a developer of design data management tools for ICs.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.