search

sdnellen / open-register-design-tool

Tool to generate register RTL, models, and docs using SystemRDL or JSpec input
Apache License 2.0
15 stars 3 forks source link

XML Data Dictionary #3

Open sdnellen opened 5 years ago

sdnellen commented 5 years ago

From open-register-design-tool created by WebMonkey007: Juniper/open-register-design-tool#52

The current XML output includes the Instance view but does not include the "data dictionary "

ie addrmap counters { counter_t transaction_cnt[10]; counter_t error_cnt[5]; }; so the xml will list tranaction_cnt and error_cnt but there is no indication that register def is the same.

I would be useful to include a "type" tag in the instances and a "data type" tree in the xml or a parallel xml file.

sdnellen commented 5 years ago

Understand request - it has some benefits.
Just fyi, a couple reasons this feature was considered lower priority:

amykyta3 commented 5 years ago

FYI @sdnellen, I have also noticed this limitation in RDL's semantics for type names & dynamic assigns. If you're interested, I'm putting together a proposed behavior to uniquify type names here: https://github.com/SystemRDL/systemrdl-compiler/issues/29

ps: congrats on the new gig!

sdnellen commented 5 years ago

Thanks, will take a look!

sdnellen commented 5 years ago

Would probably shy away from modifying the type name in favor of a hash-based approach. Then provide users with a method/property indicating if the given type is overridden and methods to test for type equivalence based on appropriate set of component attributes (and special bonus points for allowing adjustment of equivalence based on output being generated ;) - this has proved useful). Issue with just using the name is that hierarchy types are broken, eg if a register contains multiple modified fields, each of these would need to be conveyed via a new register type and likewise with regfile/addrmap types, as a single change in a sub-component really means that the hierarchy component isn't identical to one without the child change. With hash/equivalence check, each level can verify it's own properties are same and also that it has equivalent children. Maybe you have a solution for this, but didn't see in brief description.

On Fri, Sep 20, 2019 at 1:34 AM Alex Mykyta notifications@github.com wrote:

FYI @sdnellen https://github.com/sdnellen, I have also noticed this limitation in RDL's semantics for type names & dynamic assigns. If you're interested, I'm putting together a proposed behavior to uniquify type names here: SystemRDL/systemrdl-compiler#29 https://github.com/SystemRDL/systemrdl-compiler/issues/29

ps: congrats on the new gig!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sdnellen/open-register-design-tool/issues/3?email_source=notifications&email_token=AADJ4OKFOYUGRWXPHFUWKY3QKROFLA5CNFSM4IG4V3M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7FTV7Y#issuecomment-533412607, or mute the thread https://github.com/notifications/unsubscribe-auth/AADJ4OORAJINOQVTF2YAG5TQKROFLANCNFSM4IG4V3MQ .