report status of DUH document

[drom]

Add duh status command to report the general status metric about the document:

component

The total number of:

• ports
• width of all ports
• bus interfaces
• unmapped ports
• memory spaces
• address blocks
• registers
• fields

[adeelliaquat-lm]

Hi,
Recently, we started working on Duh and came across this issue.
We were successfully able to modify duh and add a status command, which is run by “duh status ”. It would be great to get your feedback on our work, so the required improvements can be done.
Picture 1 shows the result of duh status, Does It suffice ? or are we missing something?
Moreover, do we want to display any additional details? like shown in pictures 2 and 3.

Picture 1:

Picture 2:

Picture 3:

[Ramlakshmi3733]

Love your work! thank you.

Some thoughts:
a) does it make sense to dump out the interfaces by name and type including VLNV
b). When dumping out the interfaces, option by user to dump out the ports associated with each interfaces
c) dump of parameters/properties with default values

Since JSON5/DuH is readable format, the above may seem unnecessary.

What are the management utilities that could be done with the capability written?
a) A Component with very few interfaces is DuH-compliant but useless

[adeelliaquat-lm]

Thanks for the response, really appreciate your feedback.
In case of additional information like ports, associated with each interface, a user option is a good idea but as you mentioned, displaying it may be unnecessary.
So, should we proceed with the general status metric of the document, as shown in picture 1?

Love your work! thank you.

Some thoughts:
a) does it make sense to dump out the interfaces by name and type including VLNV
b). When dumping out the interfaces, option by user to dump out the ports associated with each interfaces
c) dump of parameters/properties with default values

Since JSON5/DuH is readable format, the above may seem unnecessary.

What are the management utilities that could be done with the capability written?
a) A Component with very few interfaces is DuH-compliant but useless

[Ramlakshmi3733]

yes please. we would appreciate it greatly.
The only enhancement i would request:
Where you have "Bus Interfaces: 2", it would be great to list the type of interfaces and number [forget the port map]

[adeelliaquat-lm]

yes please. we would appreciate it greatly.
The only enhancement i would request:
Where you have "Bus Interfaces: 2", it would be great to list the type of interfaces and number [forget the port map]

Tried to do the required modifications. The figure is attached for your reference.
Moreover, I have added a short description of some metrics. Would love to hear your comments on it.

bus interfaces:
Shows the total no of interfaces, present in busInterfaces (in .json file)
If the busInterfaces (in .json file) is not empty, it shows the following information:

• number: Increments as the number of interfaces increases
• type: Shows whether the interface is master or slave type. In case of bundle, type shows null
• name: Shows the name

Un-mapped Ports:
It shows the total number of un-mapped ports. In the case of multiple portgroups in the busInterfaces, it shows the sum of un-mapped ports, from the selected mapping of each portgroup.

Registers:
It shows the total number of registers

Fields:
It shows the total number of register fields. In case of multiple registers, it shows the sum of fields of each register. Is this approach fine or do we want to specify fields per register?

If the above needs any modification, let me know.
Thanks

[Ramlakshmi3733]

this is awesome!
Could you please work out the details on how to check it in?
I would gladly help build testcases for you, to ensure that if there are any issues we catch it before release.

[drom]

Looks great.
In general, all ports should be mapped to busInterfaces (VLNV or bundles). I think it makes sense to make Un-mapped Ports number red when it is > 0.

Also, it makes sense to report a total width of all ports (except when the width is an expression). Or even total number of input and output bits:

Input width: 123 bits,
Output width: 2340 bits,

Please use the following guideline on filing the PR
https://github.com/sifive/duh/blob/master/.github/CONTRIBUTING.md

[adeelliaquat-lm]

Looks great.
In general, all ports should be mapped to busInterfaces (VLNV or bundles). I think it makes sense to make Un-mapped Ports number red when it is > 0.

Also, it makes sense to report a total width of all ports (except when the width is an expression). Or even total number of input and output bits:

Input width: 123 bits,
Output width: 2340 bits,

Please use the following guideline on filing the PR
https://github.com/sifive/duh/blob/master/.github/CONTRIBUTING.md

Thanks for the suggestions. We've done the required modifications, which are as follows:
1: Un-mapped Ports are displayed in red if they’re greater than 0, else they’re displayed in white
2: The Calculated width of I/O ports is displayed

Samples are attached for your reference. Picture 1 shows a scenario where one or more expressions were present in port widths, while Picture 2 shows the one with no expression and some un-mapped ports.

Picture 1:

Picture 2:

[adeelliaquat-lm]

this is awesome!
Could you please work out the details on how to check it in?
I would gladly help build testcases for you, to ensure that if there are any issues we catch it before release.

Thanks for appreciating our efforts. For the test cases, we have populated a sheet (link given below), Please have a look at it and give your feedback. Your guidance will enable us to further mature duh status for PR.

Link : https://docs.google.com/spreadsheets/d/1-IEBhSii1OXSv9rkEgYabcqE85qlReMO-t4U_2tf-D4/edit?usp=sharing

[adeelliaquat-lm]

@drom @Ramlakshmi3733
As per above discussion, PR is pending. Your feedback is much appreciated.

Thanks