Based on DVCon 2010 paper on SystemVerilog Assertions – 2009 (see www.cvcblr.com –> Publications) we recently got our FIFO model run through NextOp’s BugScope tool. It produced some interesting stuff. The main one I liked is
pop |-> full;
This is an eye opener property – as this should never be the case! But BugScope indeed indicated that we are missing this – either as assert or cover. Obviously this is not a good assert, so when we analyzed deep, it turned out to be a “valid coverage” based on the RTL written. Details at:
So essentially we did have a coverage hole – when that hole is analyzed, we get a design error/bug! What an interesting go-around way of detecting bugs – who cares, as long the bug detection is automatic, it is good!
That could be a killer combination for specific functional verification goals. For instance look at recent SNPS’s webinar on MVRC & Formality @ http://bit.ly/9oupo9
Other ideas I have on using Formal equiv checker in functional verification are to automate Gate Level debug, debugging X’s, porting RTL TB’s to GLS etc. Need a good API + formal tool for all those ideas though…
For all those System Verilog geeks, lovers, followers here is a sigh of BIG relief – at last we have a UNIVERSAL Verification Methodology that all the 3 major EDA vendors would openly support (and hopefully promote as well). As we speak, UVM-EA (Early Adaptor) release is now available. Take a look at it from Accellera site.
CVC (www.cvcblr.com) has been constantly following this release and are about to release our fresh trainings on this UVM. After all it is based on OVM 2.0.* on which we had successful trainings delivered to several customers locally. The most recent one just over the last weekend! (Yeah, we do have weekend classes as well).
So, what are you waiting for? Go ahead and ask for our upcoming UVM class via email@example.com or call us via +91-9620209226
Talk to you soon on UVM!
A good discussion on another forum where our CTO talked about these choices in System Verilog when it comes to functional verification. Find details below. Another aspect to consider is the built-in scoreboard components becoming available with standard verification methodologies such as OVM, VMM and soon UVM. They all use Queues and some assoc-arrays as well.
And recently at ClubT India I learnt that Specman has now added this as an update to OVM-e scoreboard as well. So good for those Specmaniacs too!
Enjoy further reading below.
Queues in SV provide more search related functions such as “find_first/find_index” etc. that aid in scoreboard modeling. It is true that assoc-arrays are slightly better at memory foot-print. Also indexing can be done via any field there, not in Q – but in Q one can use the “find_first..with” to do the same.
As you can see above – this debate is meaningless after a point (as our friend Keith/Metta pointed out nicely) – you use what is easy for you. Another aspect to consider is tool support.
As of today I’m aware of 4 EDA tools nicely support Qs, few have issues/limitations with assoc-arrays though. So check your tool doc too before you make a choice.
— In ASICDESIGN@yahoogroups.com, Cool Cake <cool_cake20@…> wrote:
> For this question , they posted answer as “queues” in a website.But I think associative array’s are better suite in building score board.Because indexing is of any type where as in queues indexing is only of integral expression is allowed.
> I am bit confused here .But in my point answer is an associative arrays.
> I welcome all your views and what’s your take on this.which one is used or which one best suites?.