Unintuitive layout if ucis:covergroupCoverage hase more than one ucis:cgInstance

[eyck]

I use the viewer with FC4SC (which is SystemC/C++) which works fairly ok. Now I started to instantiate a cover group class several times and then the layout becomes a bit unituitive as the first cgInstance is shown as the covergroupCoverage entry:

If there just one cgInstance this looks fine and shortcuts the tree a bit but with more than one my user start to wonder....

[mballance]

Hi @eyck,
Thanks for raising this issue, and good to see that FC4SC is outputting UCIS schema-compliant XML. That wasn't always the case.
Is it possible for you share the XML coverage database for this example? I think I know what's being done, but want to confirm.
I could see doing one (or both) of two things to make this more consistent:

• When only type coverage is present for a covergroup, mirror that type coverage as an instance (clearly, the instance and type coverage are the same). Coverage viewing tools that I've used always show instance coverage, and this would align pyucis-viewer with that behavior.
• Provide a viewing option to filter-out instance coverage.

Thoughts?

-Matthew

[eyck]

TGC_A_AHB_coverage.xml.gz
Attached an XML database.
Actually, I had to fix FC4SC to write out a somehow compliant XML, I also opened a PR to fix this (to some extend).
My attempt would be to have the same behavior as of now if there is only one cgInstance (like underneath the dbus_access_coverage covergroup) and show the cgInstance nodes as childs if there are more than one.
I don't know if this makes sense, I'm not an expert in this. But I think even when rolling up the caoverage this would be the stuff I'd like to see.

[eyck]

Actually I see this behavior in pyucis when trying to generate a text only report. Shall I move the ticket over?

[mballance]

Let's figure out what we're doing first. This may still impact both creation of the data model that pyucis creates and the graphical viewer.
Thanks for sharing the XML data. I went back and reviewed the language in the UCIS standards document to refresh my memory, and remembered a point of confusion.

I'm beginning to get the feeling that I've misinterpreted the UCIS spec for the XML format. I had made some assumptions that the XML has a similar structure to the data model accessed via the API, and that may not be the case.

The UCIS API maintains two representations of a covergroup: the covergroup type and the covergroup instance. The covergroup type records aggregate information about what has been covered by all covergroup instances. Each covergroup instance (under the covergroup-type scope) records coverage information for an instance. It's legal to have a covergroup type scope with no sub-instances.
The XML reference states that there will be a single cgInstance entry if only type coverage is recorded (the coverage is meant for the covergroup as a whole). So, how is coverage for multiple instances recorded? And, how do we record type information when instance information is present?
My interpretation was that the first cgInstance in a covergroupCoverage was always the type coverage, and additional entries recorded instance coverage. So, the XML to record coverage for two covergroup instances will actually have three cgInstance entries:

• The type-coverage entry that contains the aggregate coverage of the two instances
• Two instances that record the collected per-instance coverage

What I'm noticing is that the covergroupCoverage entity doesn't contain any details to enable identification of the covergroup type. On the other hand, the cgInstance entries do via the cgId sub-element. Let me investigate a bit more.

[mballance]

Believe we concluded this was a PyUCIS issue, so closing this issue.