RE: [dita-sidsc] bitFieldReset issue

["McQuaid Doug-RA0727" <ra0727@freescale.com>]

Title: Re: [dita-sidsc] bitFieldReset issue

Yes, that's the way I remember it.

 

The bitFieldResetValueSource field was intended for pulling the value from a signal (internal or external) or another register.  The bitFieldResetValue was to be used when there was a static/hard-coded reset value.

 

The data model was designed to allow for different triggers to pull reset values from different sources (and to have a short-cut for pulling in static values).

 

Doug McQuaid

---

From: Beims Bob-RWBC70
Sent: Monday, January 11, 2010 12:01 PM
To: Semiconductor Information Design Subcommittee
Subject: Re: [dita-sidsc] bitFieldReset issue
Importance: High

Because a <bitFieldPropset> may contain more than one <bitFieldReset> element, would this not be coded as:

<bitFieldReset>
   <bitFieldResetTrig>System Reset</bitFieldResetTrig>
   <bitFieldResetValue>0</bitFieldResetValue>
</bitFieldReset>
<bitFieldReset>
   <bitFieldResetTrig>POR</bitFieldResetValueResetTrig>
   <bitFieldResetValue>1</bitFieldResetValue>
</bitFieldReset>

Am I missing something in your question?

Then I’m thinking there might be a case where this would be the appropriate coding for a third child of the same <bitFieldPropset>:

<bitFieldReset>
   <bitFieldResetTrig>Soft Reset</bitFieldResetValueTrig>
   <bitFieldResetValueSource>SoftResetControlBit</bitFieldValueSource>
</bitFieldReset>

I think the data model supports that, right?

Bob

---

From: Park Seth-R01164 <R01164@freescale.com>
Date: Mon, 11 Jan 2010 10:10:56 -0700
To: Semiconductor Information Design Subcommittee <dita-sidsc@lists.oasis-open.org>
Subject: [dita-sidsc] bitFieldReset issue

I'm having trouble understanding the intent of the bitFieldRest rules in the most recent lang spec (http://www.oasis-open.org/apps/org/workgroup/dita-sidsc/download.php/32513/ditaref-sidsc-book-d-090512-review.pdf)

It says that "The <bitFieldResetValue> and <bitFieldresetValueSource> elements are mutually exclusive," which means that you can have...

EITHER

<bitFieldReset>
   <bitFieldResetValueSource>HRESET</bitFieldResetValueSource>
   <bitFieldResetTrig>System Reset</bitFieldResetTrig>
</bitFieldReset>

OR

<bitFieldReset>
   <bitFieldResetValue>0</bitFieldResetValue>
   <bitFieldResetTrig>System Reset</bitFieldResetTrig>
</bitFieldReset>

BUT NEVER

<bitFieldReset>
   <bitFieldResetValue>0</bitFieldResetValue>
   <bitFieldResetValueSource>System Reset</bitFieldResetValueSource>
</bitFieldReset>

I'm trying to capture a field definition of a field that has a different reset value when the reset source is from a "Power on Reset". When it is a system reset, the field resets to "0"; when it is a POR, it resets to "1". But the data model does not allow this combination.

Can we agree that this is a valid combination and that the DTD/spec should be relaxed?

 
-seth
--------------------------------------------
seth park
information architect
Freescale Semiconductor, Inc.
seth.park@freescale.com
512.895.2463