Realities of IP reuse, from Verification perspective

IP reuse, RTL/Design IP-reuse to be precise has been in effect for over a decade now, thanks to the time-tested RMM book, http://amzn.to/bI04yK and the extensive support of those rules/guidelines/policies by Lint tools such as SpyGlass, ALINT (from www.aldec.com), and recently Ascent (from www.realintent.com).

However while talking to a customer recently on their Printer SoC verification challenges, some interesting facts/stats emerged:

• Yes we reuse IPs, they are Si-proven, but…

New SoCs use these IPs in very different context leading to:

• Different configurations that were never used/tested/verified before
• Order of configuring these IPs can make-or-break the systems

The “ordering” was more interesting and in recently concluded CDNLive India, Deeapk from Freescale Noida presented an excellent paper on: “Corner Case Verification with IFV and assertions”. While much has been blogged about the recently concluded event CDNLive, this paper didn’t get enough mention – atleast not as much as it deserves IMHO. Deepak had 3 excellent case studies:

1. Order in which IPs get configured can make-or-break the SoC. Traditional Code cov can not locate it. His team wrote those assertions manually and used IFV to verify them
2. During Power Shutdwon if there is a pending interrupt to be serviced, after wake-up that interrupt was forgotten – a pretty tall order for traditional code-cov to catch it. True one could write a test – only if you had thought about it!
3. Clock control from PLL and other enables

All these are quality bugs, but hidden in the given module for more than 1 tapeout and used in customer designs. They get exposed only with modern use scenarios and hence is the stress on increased quality, hence the need for IFV.

While Deepak’s team has successfully demo-ed the 3 corner cases, arriving at them was by no means a small task. Also who knows, how many such hidden gems/bugs are out there yet to be caught?

So while IP reuse sounds old, the verification of them is by no means is a done-deal. Great for WE all – those love Verification as it presents a good challenge.

Now just before I close this entry, a quick preview of an emerging technology that is well poised to change this scenario for sure – by generating QUALITY white-box assertions automatically for YOUR designs:

Looking beyond the current tools, emerging technology such as BugScope from NextOp (www.nextopsoftware.com) can greatly assist in identifying such corners from your RTL design and current simulation runs. You just need to see a demo/webinar or read carefully their Whitepaper http://www.nextopsoftware.com/assertion-synthesis-assertion-based-verification-whitepaper.html to explore more.