A question about functional coverage

For instance,a 16 bit multiplier is designed.It is impossible to test all possible inputs and its outputs.Then,when we do verification how can we say this mulitiplier's function is right?

it depends on your design
for example
for signed multiplier
you can try all classical condictions, and then generate some random inputs to test
plus and plus
negative and negative
plus and negative
zero and plus
zero and negative
the maximum plus and the maximum plus
the minimum negative and the minimum negative
the maximum plus and the minimum negative (and reverse)
zero and the maximum plus (and reverse)
zero and the minimum negative (and reverse)

I think you mean code-coverage,there are many good tools for such request. Recently,I heard of a certain EDA vendor from England are very powerful and dedicated on this domain,but I forget its name! Maybe you search it later.

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 !

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 !

Click to expand...

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

100 % function coverage senses when almost all the cases are proved to be correct. Here even you have to consider the slightest of the scenario according to the specification. Need to look into what the case is and what kind of acknowledgement is from the destination. On the whole considering every possible case which can happen in the real environment


Regards