Edit_Bins OSVVM

Why OSVVM™? Forums OSVVM Edit_Bins OSVVM


Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #1210
    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.
    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

    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
    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
    the probability of Human Error when writing this is VERY HIGH.
    Better to do it as below
    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.

    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
    end LOOP;
    -- Turn Merging on
    -- 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

    Thanks for your very rapid reply.

    What can we do if we want AT LEAST VALUES on a diagonal to be legal
    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,

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.