Coverage definition / model

Hi,

Over my verification experience I have been thinking about how to define a functional coverage definition which doesn’t overlap with what is covered by the code coverage. In the past, I have written functional coverage on input packets (individual fields), but started wondering "is this not covered in code coverage ? Could anyone suggest how to go about it ? Is there any example ?

Also, in one of the sessions in VAcademy, I see Tom saying that functional coverage can be collected on the outputs as well ? So far, I am under the assumption that functional coverage is only for stimulus (or inputs). Could you suggest an example of a functional coverage on the outputs.

Also, I am not very clear using functional coverage for checking the behaviour. Is this a correct approach or not ? for example, let us say certain behavior is not supported. Having an assertion or scoreboard to check this behaviour perfectly makes sense to me. But, what do we achieve by covering the property or such a behaviour ?

Regards,
Madhu

Madhu,
Good, CDV methodology questions/topics. Usually not so easy to cover in full in a forum, but will try addressing it briefly.

is this not covered in code coverage

Many a times there is some overlap and is not necessarily a bad thing. Though over doing it at times hurt engineering efforts. There are several advantages with FCOV:

  1. Model is user controlled, so can be prioritized vsi-a-vis CCOV. Of-course one can argue this is extra work…
  2. Concept of binning is hard to achieve using CCOV
  3. Transition bins are even more harder
  4. Cross cov is very difficult at times not possible with plain CCOV
  5. Query API is easier to use (relative to CCOOV). Some customers write reactive TB to achieve auto-coverage-closure (There was one good paper submitted to DVCon India 2014 on this from a local, reputed service company for instance)
  6. User can control the sampling
  7. Can represent HIGHER level abstraction if done well
  8. On a large vector one could do “bit toggle” coverage easily in FCOV (a la toggle cov, but more focussed).
  9. Extending #8 → we can also do “cross every bit” type coverage. Very useful for address decoder type of scenarios. We wrote e-macros back in early 2000’s for doing this (though using E then)
  10. Portable across tools, sometimes CCOV varies across tools.

functional coverage is only for stimulus (or inputs).

Of-course not! FCOV is on “class elements” (Can also be module/interface). It can be from input monitor or output and internal DUT stuff. Consider an address decoder and ensure that every slave is selected, for an example.

Also, I am not very clear using functional coverage for checking the behaviour. Is this a correct approach or not ? for example, let us say certain behavior is not supported. Having an assertion or scoreboard to check this behaviour perfectly makes sense to me. But, what do we achieve by covering the property or such a behaviour ?

Best methodology Question among these - you wrote some checker/SBRD, but how sure are you that the simulation hit those cases? Consider an IPv6 routing algorithm - there are several branches/cases/corners of the reference model. You need “coverage” on it. This is also a good argument for #1 above - CCOV can’t (today with tools) work on class methods.

If you are looking at “illegal bins” as a specific case, I usually don’t recommend that, instead an assertion is better!

As I said in the beginning this is a wide topic. We even offer a 1/2 day to 1 day CDV workshop at CVC/VerifLabs (www.veriflabs.com, www.cvcblr.com) for these. But we need educated audience for this such as you. Usually folks want to combine this with regular SV training, one can’t do justice to that. Contact me offline (srini <> cvcblr.com) if interested.

Srini

In reply to Srini @ CVCblr.com:

Thank you Srini for the answers.
I would like to understand guidelines or recommendations or rules that would help define a robust and meaningful fcov which really adds value. I am trying to understand streamlined thought process which would lead to defining such a coverage plan. Yes, I have defined and wrote functional coverage earlier. But going forward I would like define coverage to reduce the overlap of code coverage as less as possible.