semiconductorman said:
mhytr,
100% funcitonal coverage does not mean that you try to cover all the possible input values that can be excersied !!! instead it is to say that you have covered all the senarios that can occur to the system . The typical scerinos for your example is already put up in the above post , may be u can think of more , Get the list reviewed and then when u find there is nothing more to add . cover all of them and vola ... 100% funcitonally covered !
I agree with seciconductorman!
in fact, some basic steps are used to achieve this 100% functional coverage goal. Here it is:
<1> analyze the device spec
<2> scope the verfication objectives
<3> identify the features set of the design
<4>Design detailed coverage models
<5>select aggregate metrics to track progress
<6>use historical metrics to estimate effort and schedule
The features set mainly depend on your application, i.e., your system spec requirements. It's impossible to list all the features that for the possible scenarios that this module will encounter. Of course, if you want to write an IP, then the features shall be complete as much as possible; however it's still impossible.
Therefore some sub-optimum steps are provided:
<1> list the basic sanities, which also means the basic features that this system will encounter
<3> list the hard-to-reach cases, which also means the scenarios will take longer time to be verified. for example, the very deep FIFO status testing
<4> use random test sequences to very some conditions that you may miss
<5> for the block functional coverage, some static formal tools may help it. you may search some related topcis on mentorgraphic's web.
Thomson