Getting to IP Functional Signoff

by
Bernard Murphy
Published on 06-01-2017 05:00 AM
0 Comments

Linkedin

Facebook

Twitter

Email

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 youre 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 dont know in advance how an
IP is going to be used, the more complete checking offered by formal methods becomes
important. But theres a challenge - IP teams cant 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, its 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, youre 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.