In parts one and two of this series we looked at how to use policy classes to implement an extendable coverage model, where ignore bins can be tweaked. The first post looked at how to use these policies as parameters for a parameterizable coverage collector (the so called static flavor), while the second post focused on using them as constructor arguments for the collector (the so called dynamic flavor).
Nice series.
I like your e - view, and the way you’re trying to recreate the capabilities you miss.
I use a lot of macro generated types, where the basic covergroup with coverpoint per item are defined. when I want to add a specific cross I inherit the types, add my cross, and sure, factory override it!
your post got me thinking to add cross coverage to already defined covergroup using the existing coverpoints,
Another possibility to use dynamic “Policy” (dynamic is called algorithm pattern, I think) is to put the object in a configuration object. which is also done in build phase. Not that I’m against overrides, I would have done the override straight from the top, without going into the build. Objects/Components are heavy with factory infrastructure that propagates the override into your object, your super.build() is searching this list anyway. So why not use it? declare that override from the test, without touching your build phase.
Looking back at the last example I notice that it isn’t really that good. In a normal use case, you’d have the coverage collector already created in the base (generic) environment. Somewhere in the testbench we’d need to replace the policy object. That could be done anywhere: in the build of the test, of the testbench env, etc. Like you point out, the policy could also be a part of the config class and the testbench would override it when it’s configuring the CPU env.
How can I delete entries of sampled coverage if a reset is encountered in the middle of simulation and you want to discard previously sampled data and resample?
I’d also love to be able to do this, to make transition coverage truly useful, but I don’t know any way of doing this and I’m afraid it’s not possible.
Generally, I’d expect coverage in classes to be more controllable/extensible than coverage in interfaces, because it’s easier to access other info related to TB configuration.