Edit_Bins OSVVM

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.

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