Reply To: Merging coverage databases

[Jim Lewis]

Hi Lyle,

Case 1:

To be able to run many simulations at the same time, a test randomizes its configuration, saves the coverage database, and then runs its test.  The next test reads the previous tests database, randomizes, updates the database, then runs its test.  The limitation then is that tests must be started in a structured manner to ensure that each test works with an updated version of the database.   

Case 2

This case does not really apply to OSVVM.  The reason for this approach is all about constrained random.  With constrained random, there are no constraints derived from the coverage model.  Nothing in this approach drives a simulation toward coverage closure other than running many, many tests.  Hence, we create different test cases that use different seeds, or slightly different constraints or controls.  We run tests and each test collects functional coverage across all aspects we are interested in.  

With OSVVM, within each testcase, we create a targeted functional coverage model for what we want to see during that test.  Intelligent Coverage drives a test to coverage closure by only randomly selecting items among the coverage holes.  

None the less, it is simple enough to add merging, so I plan on adding it in the next revision.  I would not want someone not to try out OSVVM because merging was not there – even if after they try out OSVVM, they never end up using merging. 

Jim