dita-sidsc message

Subject: FW: Unresolved Issues from Review of SIDSC Spec, Draft 3

From: "Beims Bob-RWBC70" <bob.beims@freescale.com>
To: "Semiconductor Information Design Subcommittee" <dita-sidsc@lists.oasis-open.org>
Date: Tue, 12 May 2009 12:30:02 -0700

SIDSC team;

You should have already seen two automatic emails announcing that Draft 4 of the SIDSC spec have been uploaded (the DITA source files and a new PDF). On tomorrow's teleconference, perhaps the first order of business will be to talk through the unresolved issues enumerated by Noreen McMahan in the email below.

BTW, in case I did something to suppress the automatic emails, the new draft versions are @

Regards,
Bob

From: McMahan Noreen-RA1141
Sent: Tuesday, May 12, 2009 9:24 AM

p. 63. registerPropset. Annette notes that all elements contained within registerPropset are shown to have an instance of ONE. However, for addressOffset: We sometimes have more than one address associated with a register (a separate address for each access type). For registerResetValue: we sometimes don't provide a reset value at the register level.

We need to verify whether we need to change the DTD. Here are 2 use cases requiring more than one or less than one.

p. 78. bitFieldPropset. Is the bitFieldAccess field required? We don't always idetify the access type at the bit level.

p. 84. bitFieldAccess. Annette: Are we restricted to the values defined here? (Does DITA check?) I think there's at least one more possibility for a reserved field (I'll have to verify.)

Bob: We are not restricted and DITA is not going to check. This would have to be tool enforcement. Annette needs to check and let us know about whether she has another case for reserved. (I've sent the query to Annette).

p. 86. bitFieldRadix. Annette: Would this have to be defined and displayed for every bit (could get lengthy). Can this element default to binary unless otherwise specified? Bob: Good question for the team. Can we default to binary?

p. 89. bitFieldResetValueSource. Annette points to the following statement: "The "actual" is the default behavior if <resetValueSource> is not specified." Annette says, "I don't think this is correct. If <bitFieldResetValueSource> is not specified, <bitFieldResetValue> provides the value."

p. 91. bitFieldValues. Tom points to the <bitFieldValueGroup> element contained in bitFieldValues and says, "Instead of ONE instance, the value should be 'any number,' but this may not be a good idea since its parent is also 'any number.'"

p. 93. bitFielfValueGroup. Annette: "Are we anticipating that a single field will have multiple types of values? I guess that's

possible."

p. 18. componentInstanceVariables. (I put this at the bottom because it is the longest discussion.) Here is the unclear part of the description for the componentInstanceVariables element:

"The element values contained within this element will potentially override configuration settings within the component (e.g., feature enables, buffer count depth, channel count, etc."

Annette commented as follows: "I don't understand the highlighted sentence. - Where are the configuration items set? How does the override work?"

Tom responds as follows: This is a way to pass in "replacement" information to an instance of a component. Here are a couple of examples (and I believe the first was the motivating one):

We often have SoC with multiple instances of IP (e.g., 3 ethernet controllers); each has registers but they are at different base addresses. Each would have a componentDataKey/componentDataValue pair with "baseAddress" as the componentDataKey value; the componentDataValue value would be the respective address for that instantiation of the IP.

Our DDR controllers have 8 chip selects but on some SoCs we're only using 4 or 2 or 1. (Like some of the other examples in the wording "buffer count depth, channel count" this makes more sense if you think about the IP block as a whole - not just the registers but the rest of the IP as well.)

Noreen McMahan

Freescale Semiconductor

6501 William Cannon Drive

Austin Texas 78735

Phone: 512 895-3175

Cell: 512 750-0151