Ralf Hildebrandt Posted February 17 Report Share Posted February 17 IEEE 1685-2014 provides the <isPresent> element. Chap. C.10.2 says "When nonpresent, the enclosing element and all of its descendants shall be treated as if they do not exist in the file." But what does "not exist" mean? Let me explain the problem by an example: In a hardware peripheral there is a status or control bit, but this bit is only available if an optional feature is enabled. The feature can be selected / deselected before the hardware peripheral is implemented. This means, that the related flip-flop is included in the hardware or not. But if some software reads from a register (= from an address) that contains that field (= contains this status / control bit) what behavior can the sofware expect if it does "not exist"? The most straightforward expectation is "read-only, read as 0". But it is imaginable, that it could be also "read-only, read as 1". I was unable to find any definition inside IEEE 1685-2014, that defines what can be expected it something does "not exist". Does this mean, that it is not defined by IEEE 1685-2014 and therefore is implementation-specific? If implementation-specific how we can deal with the fact, that there may be (software) tools, that read an IP-XACT XML and may do the interpretation of something, that does "not exist" in a different way? And now comes the real tricky part: What if a field is <virtual> and located inside an <address block> where the <usage> is <memory>? What if such a <virtual> <field> does "not exist"? Does this mean "read-only, read value unknown" or "readable+writable, read value unknown" or something similar? For details about a <virtual> <field>, see: Next: typical address maps will contain "holes" (unused addresses) and register words may also contain "holes" (unused bits). Those "holes" also do "not exist" in an IP-XACT description. What do tools expect how those "holes" behave if a read access is done to such an "hole"? (In other words: The question is not limited to <isPresent>.) Or is there an easy way of how to define the behavior using IP-XACT? It did experiment with defining "holes" in registers as "reserved". But the problem is, that If I define a bit, I have to give it an unique name (unique at least for <fields> inside the same <register>). So it becomes rather ugly to define a bit with e.g. name "reserved_1" and "reserved_7" (if both bit positions 1 and 7 are "holes" and do "not exist"). In addition to the ugly names these definitions will be propagated through all tools (e.g. for software header file generation). This may cause trouble for header files, but becomes a nightmare if some (human-readable) documentation is automatically created by parsing the IP-XACT description. Many thanks in advance Ralf Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.