I’ve got a block level checker for one of my components… it’s a module, which I bind in (because my component is VHDL).
At an integration level, I’m hesitant to bother with binding in this checker module to the component, primary because:
I am leaving the functional verification intact, just asking about the temporal stuff.
In reply to bmorris:
Am a bit confused on your terminology in this post but assuming you are using SV/SVA bind to a VHDL entity:
Your first concern doesn’t sound valid as entity based binding is portable, you won’t need to change anything at all at integration level (unless you are using instance based binding)
Your 2nd point is unclear - are you asking why should I add that checker? If so please don’t mind me asking - why would you verify at integration level if not to “check”? I am pretty sure you have something else in mind, sorry I’m missing it.
Srini
www.go2uvm.org
In reply to Srini @ CVCblr.com:
Rewording my question a bit…
Lets say you have component compA. You build a UVM testbench, and fully verify it.
Now you drop compA into SystemA, again building a UVM testbench. Might someone then disable (or not include) some/all of the verification of compA to speed up performance. After all, compA has already been thoroughly verified in it’s own env. The primary job of the system level environment is to verify system level features, yes?
It may be a stupid question. Anyway, I think what I’ll do is to keep all my checkers (SVA, & scoreboards) and disable coverage on block level environments on a case-by-base basis.
In reply to bmorris:
The question here is, what is your definition of “fully verify it”. Here’s an over simplified and contrived example:
Say you have a design that can do task1 and task2. You omit to verify task2 (maybe because you thought that’s something that shouldn’t be used) and it’s buggy. If you reuse your testbench and the system actually executes task2, you’ll (hopefully) see some fails from the module level testbench. Since you didn’t expect task2 to be used, the module TB should yell that its assumption didn’t hold.
You could potentially also see these fails in the system level testbench (because your expected system behavior wouldn’t happen), but that means that you have a some pretty fancy end-to-end checks in place.
Functional checks you could probably safely turn off, because as you pointed out, whether you stimulate a certain case in the module level TB or in the system level context, you’re basically checking the same. Wrong assumptions about how a module is supposed to be used are what you care about. These could have either been made on module level (wrong module designed) or system level (module used incorrectly).
In reply to Tudor Timi:
Functional checks you could probably safely turn off, because as you pointed out, whether you stimulate a certain case in the module level TB or in the system level context, you’re basically checking the same. Wrong assumptions about how a module is supposed to be used are what you care about. These could have either been made on module level (wrong module designed) or system level (module used incorrectly).
I follow. So, would you likewise disable block level coverage?