Describe the problem/limitation you think should be addressed
I have a few downstream tools and scripts which require an understanding of the hwif structure and members. Currently, the hwif_report_file can be generated and parsed. However, some information (such as type info) is missing. In either case, building a hwif-member model by parsing a text file does not seem very elegant.
Describe the solution you'd like
Ideally a hardware interface API would provide a hierarchical member model, which can be iterated across and unrolled. Members should link back to the systemrdl-compiler hierarchical register model nodes, such that UDPs can be queried. When flattened, this model should provide the same information as the hwif_report_file.
Describe alternatives you've considered
So far I have subclassed the HWIFStructGenerator and InputStructGenerator_TypeScope / OutputStructGenerator_TypeScope classes, to reuse the base class methods (e.g.: enter_Field, enter_Reg, get_typdef_name) and override the add_member method. With careful attention to the MRO, I was able to build a node member model around this. From a maintainability perspective, this does not seem like a good long term solution though.
Additional context
Would this be something that is of interest? I'm more than happy to contribute.
Describe the problem/limitation you think should be addressed
I have a few downstream tools and scripts which require an understanding of the hwif structure and members. Currently, the hwif_report_file can be generated and parsed. However, some information (such as type info) is missing. In either case, building a hwif-member model by parsing a text file does not seem very elegant.
Describe the solution you'd like
Ideally a hardware interface API would provide a hierarchical member model, which can be iterated across and unrolled. Members should link back to the systemrdl-compiler hierarchical register model nodes, such that UDPs can be queried. When flattened, this model should provide the same information as the hwif_report_file.
Describe alternatives you've considered
So far I have subclassed the HWIFStructGenerator and InputStructGenerator_TypeScope / OutputStructGenerator_TypeScope classes, to reuse the base class methods (e.g.: enter_Field, enter_Reg, get_typdef_name) and override the add_member method. With careful attention to the MRO, I was able to build a node member model around this. From a maintainability perspective, this does not seem like a good long term solution though.
Additional context
Would this be something that is of interest? I'm more than happy to contribute.