What's hard to do? (limit 100 words)
When a function containing a cover node is inlined more than once into a caller — which happens naturally with loop unrolling or multiple call sites to the same function — the cover gets duplicated into one copy per inline instance. This silently changes coverage semantics: a cover in a loop should mean "fired at least once across all iterations," but the resulting Verilog ends up with N separate covers, each meaning "fired at iteration #i." The coverage counter is split across iterations instead of being aggregated, giving misleading coverage results.
Current best alternative workaround (limit 100 words)
There's no clean workaround today. A practical approach for already-built designs is postprocessing: parse the emitted Verilog, identify the per-iteration cover instances that share the same logical source/label, and aggregate their counts with a script. This requires stepping outside XLS and is sensitive to the exact naming generated by inlining.
Your view of the "best case XLS enhancement" (limit 100 words)
A single cover written inside a function results in exactly one coverage counter for it, counting "reached at least once on any iteration or path" — even when that function gets unrolled or called from multiple places. The coverage report stays intuitive: one line per logical cover in the source, with a count that reflects the intended meaning. Users shouldn't have to know whether or how inlining duplicated the code.
What's hard to do? (limit 100 words)
When a function containing a cover node is inlined more than once into a caller — which happens naturally with loop unrolling or multiple call sites to the same function — the cover gets duplicated into one copy per inline instance. This silently changes coverage semantics: a cover in a loop should mean "fired at least once across all iterations," but the resulting Verilog ends up with N separate covers, each meaning "fired at iteration #i." The coverage counter is split across iterations instead of being aggregated, giving misleading coverage results.
Current best alternative workaround (limit 100 words)
There's no clean workaround today. A practical approach for already-built designs is postprocessing: parse the emitted Verilog, identify the per-iteration cover instances that share the same logical source/label, and aggregate their counts with a script. This requires stepping outside XLS and is sensitive to the exact naming generated by inlining.
Your view of the "best case XLS enhancement" (limit 100 words)
A single cover written inside a function results in exactly one coverage counter for it, counting "reached at least once on any iteration or path" — even when that function gets unrolled or called from multiple places. The coverage report stays intuitive: one line per logical cover in the source, with a count that reflects the intended meaning. Users shouldn't have to know whether or how inlining duplicated the code.