In functional coverage, we can use ignore_bins for bins that we simply choose not to cover and illegal_bins for things that we think are impossible to cover. A benefit of the latter is that if you were wrong about the design and it actually was possible to cover them then you’ll be notified through an error (and you can investigate whether the bug is in the RTL or in your understanding).
“coverage exclude” is a code coverage equivalent of ignore_bins. Is there a code coverage equivalent of illegal_bins? I’d be interested in such a feature either when applying the exclusions through a vsim do file and/or when applying the exclusions post-simulation. Obviously, hitting an excluded coverage item with the latter method can’t raise a runtime error (since simulation is over) but the error could be indicated in the report/GUI/etc.
In reply to pdonahue_ventana:
It might help if you gave an example of a situation where you have RTL code you want synthesized but never simulated. I can think of plenty of cases for the opposite situation. Code in your testbench that should never get executed should be part of an error or fatal message.
illegal_bins was not meant for find bugs in your DUT. It was more meant for finding problems with you coverage and constraint modules. There is no way to control these kinds of messages or print out diagnosing information like you have with checkers and assertions.
In reply to dave_59:
In reply to pdonahue_ventana:
It might help if you gave an example of a situation where you have RTL code you want synthesized but never simulated. I can think of plenty of cases for the opposite situation. Code in your testbench that should never get executed should be part of an error or fatal message.
I don’t have RTL code that I want synthesized but never simulated and this isn’t about testbench code at all. Here’s the situation: Say we have a module which is a 32-bit register with a write_enable input port. We have a read-only register which is implemented as an instance of this module with .write_enable('0). Having done some analysis, I believe that it’s impossible to cover write_enable=1 in this instance so I have a “coverage exclude -scope” statement for this one instance (but not for others where write_enable isn’t hard-wired). Our design has 10 read-only registers so I should have 10 such exclusions, but I’m sloppy and created 11 exclude commands (accidentally waiving coverage on a register that is writable). Just like illegal_bins can tell me I’m sloppy, I want a similar wakeup call from code coverage.
illegal_bins was not meant for find bugs in your DUT. It was more meant for finding problems with you coverage and constraint modules. There is no way to control these kinds of messages or print out diagnosing information like you have with checkers and assertions.
I agree. My original stated goal is “if you were wrong about the design and it actually was possible to cover them then you’ll be notified” which is about finding problems with my own understanding, not design bugs.
In reply to pdonahue_ventana:
Code coverage, especially when it comes to instance specific behavior is getting into tool specific behavior. I’m guessing the exclude command could be modified to handle this situation.
This Siemens EDA sponsored public forum is not for discussing tool specific usage or issues. You should contact your tool vendor directly for support.