The conventional way of collecting functional coverage for a transaction class in RVM/VMM is through RVM/VMM callback and it generally reports the functional coverage on the random transaction generated by the generator, The functional coverage point hit or miss is purely dependent on the generated random values there is no real check if that scenario was hit in the RTL or not, meaning if you disconnect the RTL completely from the verification environment and run the test the functional converge point will still be hit.
Ideal way is to have a passive monitor hooked up to the RTL which will collect functional coverage, the idea is like sampling the values from the RTL through the passive monitor and unpacking the bytes to a transaction class object and from the transaction class object we can easily collect functional coverage. By having such an arrangement we make sure that the functional coverage point is only hit when the scenario is hit in the RTL. I know this approach requires more effort but we can be absolutely sure that the functional coverage hit will happen only if the scenario happens in the RTL. More over your functional coverage code will be isolated from rest of the verification environment code. In case of VIP development, this is the right approach to group you functional coverage model with a passive monitor.
Some of the drawbacks to this approach are the latest coverage convergence technology might not work well with this approach. You might not be able to tune or bias your constraint solver to achieve your functional coverage convergence automatically. Especially when you collect the functional coverage from RTL nodes you need to update your test bench whenever there is a change in the RTL code which affects the way functional coverage is collected.
one more reason for choosing this approach is if you have more than one way of verifying the design and we want the functional coverage monitor to collect functional coverage irrespective of the way of generating the stimulus this approach will work perfectly well.
Saturday, February 20, 2010
Subscribe to:
Posts (Atom)