Reply To: CoveragePkg useful for transitions?

[Jim Lewis]

Hi Matthias,

Perhaps I can do it.  Lets first talk about what you want.  I think you want to generate all  transitions from one operation to another.  Hence you need to generate the following conditions:

  (add -> sub), (add -> add), (add -> mul), (add-> div)

  (sub -> sub), (sub -> add), (sub -> mul), (sub -> div)

  (mul-> sub), (mul -> add), (mul -> mul), (mul  -> div)

  (div -> sub), (
div -> add), (
div -> mul), (div  -> div) 

Going further, I think you want a minimal sequence to generated this.  

> So in the optimal case I would need to perform (#transitions + 1) operations. 

I agree with this.

> With cross coverage as it is currently implemented in the package it is (#transitions * 2) operations. 

Are using the cross coverage model for randomization?  If so, how because it is going to return a pair and does not currently consider your current state.   Of course, if you just picked the current state value as the randomly generated value for your next state value, as items in the coverage model get covered, the probability that it generates a next state value that you need to cover probably will go up – interesting.  In this case, then may be it converges faster than logN.  OTOH, the value of 2*#transitions that you are currently getting is close enough to the log 16 = 2.8*#transitions to due to a “lucky”seed.  At the end of the day, one can not differentiate between luck and skill.   

With some more thought (and creative programming)  I can get it down to #transitions.   Create one coverage model for each current state (add, sub, mul, div).   When the current state is “add”, use the “add” coverage model to generate the next state and mark the new value covered.  It is not pretty, it does not scale well, but it does get the job done.   

What I am finding is that for some problems, I use one (or in this case several) coverage model(s) to generate sequences, and a separate coverage model (using cross coverage) to check my coverage (usually at an output interface rather than an input interface).   The stimulus generation coverage model may have extra stuff in it to help shape other parts of the problem – but are not necessarily even items that I track.  

Best,

Jim