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.