Getting to IP Functional Signoff

In the early days of IP reuse and platform-based design there was a widely-shared vision of in-house IP development teams churning out libraries of reusable IP, which could then be leveraged in many different SoC applications. This vision was enthusiastically pursued for a while; this is what drove reusability standards and cost-metrics, among other initiatives. But shifts in markets and fierce competition disrupted the in-house ideal. IP and EDA vendors offered extensive and growing libraries for standard IP, proven over many more designs and in many more processes than most in-house design teams could match. And for chip-vendors, the cycle time and cost to make existing IP truly reusable became increasingly difficult to justify in the face of tougher competition and squeezed schedules.

This became apparent in retrenchment to adapting internal assets as needed, design by design, rather than investing much in forward-looking reuse objectives; when you’re fighting to stay in the game, tactical priorities tend to overrule long-term strategies. Now it seems the outlook for many semiconductor suppliers has become more stable and EDA vendors like Cadence see a return to separate IP development teams and resurgence in demand for reusability. This is motivating a greater expectation of RTL signoff for IP; after all, reuse is meaningless if an IP must be reworked and re-verified for every design.

Pete Hardee (product management director at Cadence) told me that chip verification teams are now demanding a higher level of functional quality from IP teams than they had expected in the past, because they no longer have time to debug IP problems. Naturally this requires IP development teams to make a bigger investment in dynamic verification and it also requires starting to make an investment in formal verification; when you don’t know in advance how an IP is going to be used, the more complete checking offered by formal methods becomes important. But there’s a challenge – IP teams can’t afford to staff for formal experts; they must be self-sufficient, so investment in this area must require minimal formal expertise.

In support of this need, Cadence in their JasperGold product was probably the first to provide a range of autoprove apps requiring little to no expertise in formal, and has recently announced significant customer validation for two of these: Superlint and clock domain crossing (CDC) analysis. The superlint app includes the standard HAL checks, along with checks requiring formal such as overflow and underflow (no, it’s not just a width check), controllability and observability (for testability analysis) and FSM livelock and deadlock checks. CDC analysis includes structural checks (with support for multiple synchronization styles) along with reconvergence analysis and a range of functional checks, such as correct gray-coding on fifo pointers.

A very nice feature they have added is formal-supported waiver management. CDC analysis can be very noisy, producing many potentially false violations, not because the analysis is inaccurate but because a lot of what determines correct design for CDCs depends on design intent. A good example (and a source of a lot of false violations) comes from quasi-static signals.

These signals, often used for configuration control, in theory could switch at any time but in practice commonly (though not always) switch only during power-up or reset or other phases where synchronization concerns may be minimal. Since there can be a lot of these, avoiding synchronizers where possible can save useful area – but note the caveats in the previous sentence. Not every such case is a safe candidate to drop a synchronizer – some reconfiguration may be possible during active design use. So how do you figure out which of these violations are potential quasi-statics and which are safe to ignore?

JasperGold CDC will generate and auto-prove assertions to determine if violations result from quasi-statics. These will drill back to root-causes, often catching a lot more potential quasi-statics in the process. Of course, you’re going to have to make the final decision on whether the root-cause indicates those cases are indeed safe. But with minimal involvement, no formal expertise but still with high confidence you can waive lots of violations and get more quickly to clean CDC signoff. The app also supports dumping assertions for additional checking in Xcelium simulation.

Cadence has endorsements from ARM and ST for these technologies. ARM, being ARM, did a detailed analysis (reported at the last Jasper User Group meeting) of how using Superlint accelerated bug hunting during RTL development and pulled in RTL signoff, reducing the need for late-stage RTL changes by as much as 80%. ST commented on how the CDC app increased quality of design and chopped up to 4 weeks off design and verification time for each IP.

This is important – as much for how formal is becoming important in IP RTL development as for the apps themselves. The whole point of reuse is to reduce overall design time and increase design quality by sharing proven IP. Improving IP quality through better RTL signoff is an important way to get there. You can learn more HERE.