I’ve got a coverage collector which must define it’s bins based on information that only becomes available some time after the simulation has begun (during an initialization command). My first thought was to defer the construction of the coverage collectors until this command had completed, however it’s illegal to build components in the run_phase. Am I out of luck?
In reply to bmorris:
This does not seem right. How would you expect to merge coverage results from multiple tests? (or multiple seeds from the same test)?
But in any case, you can decouple the covergroup from the coverage collector class either by putting it into another class not derived from uvm_component, or outside of a class completely.
In reply to dave_59:
You could probably merge if you give the covergroup different instance names, derived somehow from the input parameters. This emulates a cross between the covered values and configuration settings.
In reply to dave_59:
At the block level, my test generates the initialization data, and pipes it through my agent to initialize the DUT. Simultaneously, the env config is also provided a handle.
At system level, the initialization data for the block-level component is coming from a text file, not the test. But, my block level environment config still needs a handle to initialization data (the most essential of which, to build cover groups).
Because mid-simulation re-initialization is not a feature that’s important to test, I simply did the poor-mans approach; I look in the initialization text file, pick out the fields that are required by the block level environment, and feed those into its config object via the test. I dont LOVE that approach, because the data exists in two places, but it’s not function critical, and only a slight inconvenience.
Were I to try merging covergroups that were different test-to-test; I’ve never tried that. I would like to think you could define some bins such as
bins correct_port0 = {cfg.my_port0};
bins correct_port1 = {cfg.my_port1};
etc.
And even if cfg.my_port0 changes from test-to-test, the bin would remain constant. Ie I dont care what port it is really, just that the “correct one” was hit. I have no idea what the tool would do if I merged 2 databases with that.
In reply to dave_59:
I decoupled the covergroups from the classes, and defer their creation until later.
The merging doesn’t appear to have any issues. for example, during one run
bin CORRECT gets tokens when my sample input = some value X
on another run, it gets tokens when sample input = some value Y.
I don’t care what those values are, just that they go into the bin.
It sounds no different than passing in an CG arg by reference. The sample bin contents could change drastically even within a single test.