Home Reviews Ignorance Is A Bliss

Search

Ignorance Is A Bliss PDF Print E-mail
User Rating: / 0
PoorBest 
Thursday, 24 December 2009 15:29

There is a rather confusing feature in Specman’s coverage engine that I would like to share with you today. I’ve met several people (including myself) who had been struggling to understand what was going on there and gave up Recently I was called to the rescue again with the same problem so I guess it’s a good opportunity to tell you guys about it.

 

So imagine you have a struct called packet. And in the packet you have a length field which could be anything from 0 to 255. You’re doing a lot of things with this packet in your environment and you also want to add some coverage. Let’s see some code:

struct packet {
length: byte;
 event cover_me;
 cover cover_me is {
 item length;
 };
};

Very simple so far. Next we want to limit the coverage spectrum of this item because we’re not interested in values over 100. We will use the ignore command for that:

item length using ignore = length > 100;

For the less experienced guys out there - note that the coverage commands ignore and when may look as two alternatives for limiting the coverage collection, but in fact they are fundamentaly different from each other and should be used for different purposes. The ignore command is used to narrow down the coverage spectrum while the when command is used to narrow down the number of coverage collection occurrences.

Back to our business, after we’ve narrowed down the coverage spectrum to values below 100 only, we want to have an additional limitation, and ignore values under 90.  Let’s do this:

item length using ignore = length > 100, ignore = length < 90;

You think this is going to work? Not really. The code will compile and run successfully but the coverage engine will only take into consideration the last ignore command. Really disappointing. This problem typically arises with more complex items such as cross items.

 

Now for the good news: the workaround is to write all your ignores in one (long) line Not so comfortable with complex items, but it’s the only way it will work. Also, make sure to use or (and not and) as a separator between adjacent ignore conditions because we’re dealing with inverse logic here.

So let’s conclude with the full example again, and a few lines of code that demonstrate it (you’re gonna have to open the coverage window to see this).

 

Here we go:

 

struct packet {
 length: byte;
 event cover_me;
 cover cover_me is {
 item length using 
 // the 2 lines below will NOT do the job
 //ignore = length > 100, // this ignore will be ignored !!
 //ignore = length < 90;
 // the line below WILL do the job 
 ignore = length > 100 or length < 90;
 };
 };
extend sys {
 !packet: packet;
 run() is also {
 for i from 1 to 100 {
 gen packet; 
 emit packet.cover_me;
 };
 };
 };

 

 
More articles :

» VMM Hackers Guide - Default Behavior For Your BFM

Here's a short tutorial on how to implement a default behavior for your BFM using VMM. Some protocols require constant activity on their interface even when you don't have any data to transmit. This means you must have a mechanism that drives idle...

» The Cost Of Verification

We spend about one third of our lives in bed, right? doesn’t it make sense then to buy a good bed and not a cheap one? The same can be said for your verification tools as you spend so much of your project time on verification. Buying cheaper tools...

» Future Trends In HR

The industry is going through some tough times, no doubt about it. We’ve seen layoffs worldwide, projects being cancelled or put off for better times. How is this going to affect the way companies manage their human resources? Joining us today for...

» Cool Things You Can Do with Verdi

Wow it's been a while, but I'm back with a new series of YouTube videos. Hurray !!This time it's all about Verdi and all the cool things it can do for you.Since most of you guys already know it is the best debugger out there, my goal is to show you...

» Review - Verification Leadership Seminar

How many of you have tried to cut on coffee? or even quit drinking coffee altogether? I guess a lot. Well, personally I’ve given up on trying but you know what? there’s actually something worse than having 8 cups of coffee per day - it’s the...

Comments  

 
0 #1 2010-01-02 05:09
Or you can use the "in" and range to make the code look nicer.

e.g. ignore = length not in [90..100];
Quote
 
 
0 #2 2010-01-03 15:53
from the post it can be understood that you must write the all ignores on an item in one place,
but this is not true since you can use "prev"
cover cover_me is {
05. item length using
10. ignore = length > 100;
11. };
12. };

cover cover_me is {
05. item length using
10. ignore = prev or length < 90;
11. };
12. };
Quote
 
 
0 #3 2010-01-03 17:05
Quoting Horace Chan:
Or you can use the "in" and range to make the code look nicer.

e.g. ignore = length not in [90..100];


Correct. Like I mentioned in the article, this problem typically arises with more complex items such as cross items.
Quote
 
 
0 #4 2010-01-03 17:10
Thanks for the insight, Ronen. But what if you don't want to extend the cover group, you just want to refine the original ignore statement with additional ignores separated by comma?
Quote
 

Add comment


Security code
Refresh

Copyright © 2017 Think Verification - Tips & Insights on ASIC Verification. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.