Edit_Bins OSVVM

[Dave Ansell]

*
OSVVM Edit_Bins
===============
ie. CHANGE Bins to ILLEGAL or IGNORE etc.

SetUp Cross Coverage with AddCross
&
then CHANGE Selected Bins to ILLEGAL or IGNORE

Edit_Bins is a VERY simple way of setting up a lot of bins & choosing some of them to be ILLEGAL.
INSTEAD of simple BUT EXPENSIVE
ACov.SetMerging(TRUE); — Ensure that ILLEGAL bins not Gen by RandCovPoint
ACov.AddCross(GenBin(16,31,1),IllegalBin(64,79,1)); — 1 Illegal Bin
ACov.AddCross(GenBin(0,255,16),GenBin(0,255,16)); — 16Bins x 16Bins

WHY?
CoveragePkg Manual says,
Merging of count bins is EXPENSIVE.
Bin merging may be REMOVED in the future. <<<——{{{{{{

Perhaps CHANGING a Bin INSTEAD is NOT expensive
if
a single item within a data structure needs to be changed.

Same argument applies to at least values etc. <<<<<<<<<<

Another Example
—————
On Page 17 of the CoveragePkg Manual we have:-

ACov.AddCross( 2, GenBin (0), IllegalBin(0) & GenBin(1,7)) ;
ACov.AddCross( 3, GenBin (1), GenBin(0) & IllegalBin(1) & GenBin(2,7)) ;
ACov.AddCross( 4, GenBin (2), GenBin(0,1) & IllegalBin(2) & GenBin(3,7)) ;
ACov.AddCross( 5, GenBin (3), GenBin(0,2) & IllegalBin(3) & GenBin(4,7)) ;
ACov.AddCross( 5, GenBin (4), GenBin(0,3) & IllegalBin(4) & GenBin(5,7)) ;
ACov.AddCross( 4, GenBin (5), GenBin(0,4) & IllegalBin(5) & GenBin(6,7)) ;
ACov.AddCross( 3, GenBin (6), GenBin(0,5) & IllegalBin(6) & GenBin(7)) ;
ACov.AddCross( 2, GenBin (7), GenBin(0,6) & IllegalBin(7) ) ;

VERY Cumbersome & it can only get worse in something nontrivial.

This is a simple example
BUT
the probability of Human Error when writing this is VERY HIGH.
SO
Better to do it as below
BUT
Bin merging may be REMOVED in the future. <<<——{{{{{{

ACov.SetMerging(TRUE); — Ensure that ILLEGAL bins not Gen by RandCovPoint
for i in 0 to 7 LOOP
  ACov.AddCross(IllegalBin(i,i,1),IllegalBin(i,i,1)); — Illegal Diagonal Bins
end LOOP;
ACov.AddCross( GenBin(0,7), GenBin(0,7) );

IllegalBin(i,i,1) is a reminder that
in other circumstances there may be more than 1 Bin per loop & it may have a Range.

SO,
WITHOUT Bin merging
we need an Edit_Bins facility that can be put in a LOOP as above.

So Jim Lewis
What do you think?

[Jim Lewis]

Short Answer:
Merging between count and illegal and/or ignore bins will continue to be supported.  That is the base feature.

Hence, the code you posted should be fine.   OTOH, in the general case, I would turn on the SetMerging on as late as possible, such as what I show in the code below (although in this case, I would expect very little difference in run time):

-- Mark all bins on diagonal illegal
for i in 0 to 7 LOOP
  ACov.AddCross(IllegalBin(i,i,1),IllegalBin(i,i,1));
end LOOP;
-- Turn Merging on
ACov.SetMerging(TRUE);
-- Add remaining bins and delete any bin that is also an illegal bin
RandCovPointACov.AddCross( GenBin(0,7), GenBin(0,7) );

Longer Answer:
The candidate for deletion is the merging of a count bin with another count bin.  
Quoting the 2016.01 revision:

Currently bin merging also merges count bins when they have identical bin values. Merging of count bins is expensive. Since this feature is correctly handled by LastIndex, it may be removed in the future.

Count bins only need to be merged if you enter a duplicate count bins as a method to add supplemental coverage to a certain set of bins.  OSVVM’s Intelligent Coverage Randomization has evolved to correctly handle this case, so merging of these items is only needed if you are not using only the Functional Coverage capability and not the randomization capability of the coverage modeling. 

The issue with general merging is that it is an O(N2) operation.   What I am looking into is keeping the illegal and ignore cross bins in a separate list to allow searching through a subset of the entire list.   This would change the operation to an O(N*M) where N is the size of the list and M is the number of ignore/illegal items (presumably << N).   

Long term, I am also looking into filtering.  Filtering would search through the list and create a sublist (of references into the main list and use them to do something), such as randomize across the subset.  

Once we have a filter, it may make sense to add a filter and edit, however, at first consideration, it does not look like it would be any better than the updated Merging capability. 

Hope this clarifies things and removes your concern.

[Dave Ansell]

Jim
Thanks for your very rapid reply.

What can we do if we want AT LEAST VALUES on a diagonal to be legal
BUT
HIGHER than the rest.

Is it still possible to do the diagonal seperately in a simple loop similar to above.

[Jim Lewis]

Hi Dave,
If you are using Intelligent Coverage Randomization, duplicate count bins are ok.

Otherwise, there are simple algorithmic solutions to that problem that do not involve merging. 

If you have taken our Advanced VHDL Testbenches and Verification class these are covered in the sections titled Functional Coverage and Advanced Functional Coverage.  Also if you have taken the class, contact me privately and I will be happy to setup a web session to walk you through them.

I would be very interested in an example of real world problem that would benefit from having merging and would not be able to use Intelligent Coverage Randomization.

Best Regards,
Jim

[Author]

Posts