Automatic generation of checkers & coverage model – A NextOp 101

 

Earlier this week John’s DeepChip ran a user survey asking for “edgy” questions for DAC-12 “Troublemaker Panel”. Here is what those came out for NextOp were: http://www.deepchip.com/items/0504-05.html

>> Yunshan, what does NextOp do and why should users buy your tool?

I am amazed at how “basic” some of these “queries” are – aren’t they supposed to be “edgy”? Sure John is doing a great job in publishing “AS-IS”, so can’t blame him for this, it is rather the typical limitation of small start-up, especially in EDA being unable to broadcast its value to masses. Here is my attempt, being a partner, promoter of this technology and SystemVerilog in general.

Assume that you are tasked with a I2C IP/sub-system verification (it isn’t that uncommon, is it?). Consider an AMBA based SoC in which this I2C is being integrated, the other side of this IP is typically APB.

Your company has tight timelines for this and has provided you VIPs a la modern day UVC (UVM Verification Component). So your job is to simply hook-up those UVCs as shown below:

 

Assuming the UVCs live up to their promise of plug-n-play by your VIP vendor, this would be a 1 or 2 days job isn’t it? Then add few more days to tighten the “scenarios”, then you are done in a week, right?

So a typical I2C verification project should be atmost 1 week project, Huh? Is life really that simple? Of-course not! – this is where NextOp plugs-in. UVM is great, and hopefully the maturing VIP industry around it can indeed provide you solid plug-n-play-able VIPs for you. This does automate majority of “stimulus” creation and some of “protocol checkers” and “functional coverage”. But what about “your design specific” checkers & coverage? Isn’t that the MOST important and hence is the reason why you are tasked with this project to start with?

So how do automate the “design specific” checkers & coverage? This is how – a NextOp 101 starts here.

 

 

You run the UVCs + RTL design as-is (after that 1 week of your project start, let’s say). Include 2 simple PLI calls:

$himafile & $himavars

This flow would eventually create a set of “properties” or “observations” that your TB + RTL is showing up during the regressions as a simple, plain English TEXT file. No, it is not a syntatically “overloaded/crowded” SVA/PSL code for your “kind review”, rather simple format such as (BTW, the below screenshot is from a  different, DDR design, just got lazy enough not to do that on that specific design):

 

Now you sit with your designers and classify them as “assertions” and “coverage holes”. Typically the designer spends 2-5 minutes per-property to decide this classification. Then you run another “utility” called “hima” that spits out SVA/PSL/OVL/Verilog assertions for you to add to your UVM bench during next random regression.

It is quite common that users identify bugs/coverage holes during the review itself than waiting for next runs!

Now quoting a reader’s question from that Jonh’s “edgy questions” (I do agree this is an “edgy question”)

 Why should we pay extra for BugScope when we can get SNPS/CDNS/MENT
  formal verification tools for "free" (or at a heavy discount) as
  part of a bundled deal?

 

Hopefully this blog entry answered it atleast partially – it is NOT available as part of any other EDA vendor as of today!

Yes, you do pay extra – bu then YOU-GET-WHAT-YOU-PAY-FOR :-)

Enjoy the ABV with NextOp!

Technorati Tags: SystemVerilog,EDA,NextOp,Assertions,checkers,coverage