Dear Readers,
Do not rely on illegal_bins for checking perpose. If you rely on covergroup where you have written illegal_bins, what happens when you turn off the coverage??
That is where Assertions coming in picture...! If you really want to ignore values then use ignore_bins. If you really want to throw errors then use an assertions checkers.
While illegal_bins removes values from coverage calculations, it also throws errors.
Philosophically, you need to ask yourself the questions,
(1) “Should a passive component like a covergroup be actively throwing errors?” and
(2) “If you rely on the covergroup for checking, then what happens when you turn coverage off?”
From the example given above, you can see 3'b100 is an illegal opcode and as per protocol if that value occurs then its an error.So here instead of writting and illegal_bins you can have a assert property with coverage to check specifically this scenarion.
So usually I would prefer to have an assertions (with cover property) where strong protocol check requires instead of writting illegal_bins.
Happy Reading,
ASIC with Ankit
Do not rely on illegal_bins for checking perpose. If you rely on covergroup where you have written illegal_bins, what happens when you turn off the coverage??
That is where Assertions coming in picture...! If you really want to ignore values then use ignore_bins. If you really want to throw errors then use an assertions checkers.
While illegal_bins removes values from coverage calculations, it also throws errors.
Philosophically, you need to ask yourself the questions,
(1) “Should a passive component like a covergroup be actively throwing errors?” and
(2) “If you rely on the covergroup for checking, then what happens when you turn coverage off?”
From the example given above, you can see 3'b100 is an illegal opcode and as per protocol if that value occurs then its an error.So here instead of writting and illegal_bins you can have a assert property with coverage to check specifically this scenarion.
So usually I would prefer to have an assertions (with cover property) where strong protocol check requires instead of writting illegal_bins.
Happy Reading,
ASIC with Ankit
3 comments:
Basically, illegal_bins are not provided for the pure checking purpose. It just inform verifier that these values are illegal OR not expected. And using illegal_bin does not mean we should not add checker. It has to be there. Coverage is enable usually all the time. User may use their own coverage model and disabled one supplied along with the VIP and do not forget to write glue logic to embedd cov model.
Dhaval
Thanks Dhaval for sharing your views.
But first thing, coverage is not enabled all the time usually. It depends and can be switch on/off as per need. And usually coverage will comes in picture during the regression phase where we are more concern about the covered functinality. Most of the time I have seen people enables the coverage once they reachs to regression phase.
I agree that we should always write a checker as it throws an error if illegal operation happens. The point is we should not rely on only illegal_bins there should always be a chekers to throw an error during the simulation.
-ASIC with Ankit
So Is there any specific use of having illeagle_bin?
As if this condition (illeagle bin) occurs, error will be sought.
Why we need to have assert property for the same.
Post a Comment