Early IP Block Error Detection is Critical!

The rising complexity of modern SoC designs, as enabled by progressing manufacturing technology, leads to an increasing validation challenge as the only way to manage complexity increase is by re-using more pre-designed IP blocks. These IP-blocks are provided by various suppliers such as a foundry partner, internal design groups, open-source IP and third-party IP companies. This is driving the trend of increasing IP Qualification costs, which is part of an exponential growth of total SoC design cost.

Cost in terms of IP qualification and design-verification is mostly found in design-time spent in verification runs and resolving the issues found. A well-known design principle is that the closer an error is detected to its point of creation, the less costly fixing it becomes. That is why design-teams deploy various techniques before accepting an IP block into their SoC design flow. Any issue found during IP qualification or incoming inspection, can be directly fixed within the IP by the IP supplier. Failing early detection, design teams are faced with the tedious path of tracing an issue in the final design back to a single IP block. After which of course the IP still needs to be repaired, re-released and re-integrated in the final design.IP qualification methods have evolved from self-certified questionnaires, through home-grown IP qualification scripting into an industry-standard IP qualification solution known as  Fractal Crossfire.

An IP qualification solution will  certify that an IP release is complete, has internal consistency and will exhibit predictable trends within and over  characterization corners. All these are must-have properties for an IP block before it can be included in any SoC design.We argue that for a design-team that is approaching tape-out, having the IP qualified is necessary, but not enough. In the scenario where a design-team is receiving regular incremental revisions of an IP block, it is also  essential that these revisions gradually converge to a steady state where changes to the IP block are limited to only  the bare minimum. If in a late stage of the design an IP block is shipped that has a large delta with respect to the   previous release, this can pose a huge risk to the final design schedule, even when the IP is successfully qualified.

Introducing IPdelta

The arrival of a new IP release close to tape-out is the high-risk scenario where IPdelta is indispensable. Anything that has ended up in this new IP release is a danger to the verification level already achieved. IPdelta will analyze the delta between the two IP revisions. Regardless of object ordering within files or databases, it will compare contents of all individual databases, models and formats and categorize the differences it finds.

Certain changes are expected — and should therefore be complete in their implementation throughout the different views. Some, or many, changes can be unexpected, indicating that the IP-release contains updates that are not necessarily needed for the current design and require further investigation. As the amount of changes can be huge, IPdelta offers users a sophisticated delta-browsing interface that allows users to quickly zoom in on changes that pose a real threat to timing and power closure

By comparing IP releases, IPdelta provides the confidence that only the expected updates are present in the new IP release so that insertion in the final design is safe.

Conclusion
It can be concluded that an IP qualification sign-off is a necessary but not a sufficient condition for safe insertion  of a new IP release into an existing SoC design. No matter how thorough an IP qualification tool is it is only made to  judge an IP release in isolation. When receiving a new IP release, designers need to be ensure that the delta between  versions is kept to the bare minimum necessary.