Edit_Bins OSVVM

Why OSVVM™? Forums OSVVM Edit_Bins OSVVM

Tagged: 

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #1210
    Dave Ansell
    Member

    *
    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?

    #1214
    Jim Lewis
    Member

    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.

    #1221
    Dave Ansell
    Member

    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.

    #1224
    Jim Lewis
    Member

    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

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