Lazy scopes

[Blebowski]

Hi @nickg ,

I am tinkering with the code coverage, and I would like to try to implement basic support for statement coverage in Verilog.
I am looking at how does the "cover scopes" work currently in lower.c for VHDL. The "lower scopes" do implement some sort
of lazy code-gen (JIT). How does that work with the coverage though ? I thought the "coverage counters" are pre-allocated
at elaboration time (there needs to be known the total number of coverage bins within the simulated design). Is this not true ?

In other words, e.g. if you have a procedure that is local to a process (in architecture, not package), and such procedure is
never called during elaboration, then:

1. Lower scope, Cover scope are not emitted during elaboration.
2. Code Coverage bins are not emitted during elaboration.
3. The first time the procedure is called during simulation, the code-gen is invoked, the cover-scopes are added, coverage items are emited (the run-time counters with coverage data are re-allocated).
4. After the code is generated, it is executed (since the attempt to execute it triggered the generation). Therefore, the newly alloced coverage counters are incremented during execution.
5. After the simulation is finished, the ncdb will contain also the coverage data for the newly generated code.

Is this correct ?

If, so I have couple of questions:

1. Different simulations can trigger different code-gen to be invoked first. The order of coverage counters may be therefore different for each simulation run. This does not mind, because even if the coverage scopes are being generated in slightly different order (and therefore dumped to the ncdb), they are uniquely distinguished by their hierarchical path. Thus, scopes will never mess-up when merging the code coverage. Correct ?
2. What happens if during simulation, a procedure does not get called at all ? The code will not be generated, therefore the coverage items will not be emitted, coverage scopes added, and the covdb (and the coverage report too), will simply not contain coverage data for such procedure ?

Any tips or explanations are appreciated.

PS: Big thumbs-up to the work you are doing on the Verilog these days.

[Blebowski]

Very close to this topic is: How does it work with the signals and the JIT code-gen ?

I would assume, that code for all signals (drivers, hierarchies, resolution), is actually generated at elaboration time, correct ?
Or does the lazy code-gen works too for drivers ? E.g. a signal in the run-time model is registered (and code is generated for
its driver), first time it is assigned during simulation ?

[nickg]

I'm not sure how useful add coverage support to the Verilog backed is at this point given how limited it is.

I thought the "coverage counters" are pre-allocated at elaboration time (there needs to be known the total number of coverage bins within the simulated design). Is this not true ?

No, it's always been possible to grow the backing array after elaboration since I added the lazy code generation stuff. There should be some tests that hit this. Although it's quite hacky and was only supposed to be temporary. I rewrote it this weekend so there's a separate array per code generation unit.

Different simulations can trigger different code-gen to be invoked first. The order of coverage counters may be therefore different for each simulation run.

I don't think it matters. The content of the counters is the same regardless of the order.

What happens if during simulation, a procedure does not get called at all ?

Then doesn't have any coverage information. That could probably fixed with another pass that forces code generation for user subprograms when coverage is enabled.

I would assume, that code for all signals (drivers, hierarchies, resolution), is actually generated at elaboration time, correct ? Or does the lazy code-gen works too for drivers ?

All that code gets called at elaboration time (by elab_lower() -> create_scope()) so it doesn't really make a difference whether it's generated lazily or not.

[Blebowski]

I'm not sure how useful add coverage support to the Verilog backed is at this point given how limited it is.

Maybe not much, but I was interested in trying it :)

I see that you wrote the MIR backend for verilog. Is this something you would like to eventually use for
VHDL too ? I am asking since that will have impact on many things like coverage for Verilog, or extending PSL.

I don't think it matters. The content of the counters is the same regardless of the order.

I did not mean it would matter, as the counter value is paired with cover item that is uniquely
distinguished by the hierarchical path.

Then doesn't have any coverage information. That could probably fixed with another pass that forces code generation for user subprograms when coverage is enabled.

I don't think that is necessary. AFAICT, when someone deals with coverage, then they have complex TB
with many tests, and most of the code does get called at least once. Also, currently coverage is emitted
only for code in entities, not packages. Do I understand it correctly that a code for a single instantiated
entity is one "code generation unit" ? If so, then as long as the entity is instantiated, code coverage data
for it will be collected.