Dear Readers,
During my experience I have come across one interesting things, with that I was in little bit confuse and could not able to figure it out. I though its an interesting experience and I should share it across:
Here it is:
I have been using VCS tool in my project for verification. As I have been writing functinal coverage and assertion from last couple of months, recently I have found some interesting thing during the compilation warning:
I was using bins range with large value called {[1:65536]} with this value tool is giving and warnning given below. But the interesting thing is not a warning but the message which is comming with that warnning is more interesting.....! Below is the warning
Warning-[CPBRM] Precision or Sign Mismatch
Potential precision or sign mismatch in range values of user defined bin
block_id_illegal of coverpoint i2s_block_id in covergroup
$unit::CoverageCallbacks::static_field_cov
Source info: illegal_bins block_id_illegal = { [1:65536] } ;. Values outside
the valid coverpoint range will either be deleted(singleton values) or
adjusted(ranges) as per the precision semantics.
Please refer SystemVerilog LRM section 18.4.6
So from the message, I could understand the warning that I should not use the large value for bins declaration. But in this warning message it recommenting to refere LRM section 18.4.6 which is not there in LRM, section 18.4 does not have any sub section, and that section is for Top Level Instance not for coverage bins.
So as per my understanding there could be two things: Message might be wrong in compiler or may be there is an interpretation problem :-)
I would be pleased if you share your experience with this kind of warning.
Happy Reading,
ASIC With Ankit
During my experience I have come across one interesting things, with that I was in little bit confuse and could not able to figure it out. I though its an interesting experience and I should share it across:
Here it is:
I have been using VCS tool in my project for verification. As I have been writing functinal coverage and assertion from last couple of months, recently I have found some interesting thing during the compilation warning:
I was using bins range with large value called {[1:65536]} with this value tool is giving and warnning given below. But the interesting thing is not a warning but the message which is comming with that warnning is more interesting.....! Below is the warning
Warning-[CPBRM] Precision or Sign Mismatch
Potential precision or sign mismatch in range values of user defined bin
block_id_illegal of coverpoint i2s_block_id in covergroup
$unit::CoverageCallbacks::static_field_cov
Source info: illegal_bins block_id_illegal = { [1:65536] } ;. Values outside
the valid coverpoint range will either be deleted(singleton values) or
adjusted(ranges) as per the precision semantics.
Please refer SystemVerilog LRM section 18.4.6
So from the message, I could understand the warning that I should not use the large value for bins declaration. But in this warning message it recommenting to refere LRM section 18.4.6 which is not there in LRM, section 18.4 does not have any sub section, and that section is for Top Level Instance not for coverage bins.
So as per my understanding there could be two things: Message might be wrong in compiler or may be there is an interpretation problem :-)
I would be pleased if you share your experience with this kind of warning.
Happy Reading,
ASIC With Ankit
2 comments:
It doesnot mention anything about the LRM version u need to refer, so may be it's just the version difference and older or latest version might contain the information you are looking for ;)
Hi Jay,
I agree with you and appreciate your response as well, but the thing is it does not mentioned the respected LRM version in the warning!
I would like to mention that as per my knowledge LRM 3.1a is the latest one and after that Accelera has not announced any version of the LRM. Please correct me if I am wrong.
I agree with your comment and that may be the potencial reason why warning messages and LRM content are mismatching. If that is the case then there should be LRM-VCS version matrix from which user can have idea what version of LRM needs to refere for respecte version of VCS.
-Ankit
Post a Comment