RE: [dita-sidsc] bitFieldAccess definitions/revisited

["Ratliff Alan-R68672" <alan.ratliff@freescale.com>]

Hi all,

 

I'm resending my earlier feedback (email from 7 June below) and expanding a bit here...

 

What about multiple host access?

On a few rare but real occassions I've seen registers that can be accessed by two "hosts" coming from separate buses.   For example, a (slave) communications controller (for example, USB Device controller) within a chip needs to be programmable by the chip's CPU but might also need to be accessible to a external master communications controller.   So, when this happened to me for example, I had to preface each register with something like:  

• internal peripheral bus access:  read-write
• external communications bus access:  read only

@@@

New feedback...

 

A new access use case?:  write-once

I recently ran into another variation on accessibility. Here's an attempt at an explanation for write-once fields ...

• write access: software can program the field only once after a reset
• read access: don't care; could be readable (or not)
• where used: for safety-critical features or any function otherwise critical to system integrity
• purpose:  to guard against accidental (programmer error or runaway code) or malicious (virus) overwriting of a field
• for example:  A system watchdog module could have a programmable time window within which software must periodically ping the watchdog (saying "all is well").  This time window should be configured once during boot-up and then remain fixed.

Thanks.

-Alan

---

From: Ratliff Alan-R68672
Sent: Sunday, June 07, 2009 8:00 PM
To: Semiconductor Information Design Subcommittee
Subject: RE: [dita-sidsc] bitFieldAccess definitions

Thanks, Seth.  It's looking good. 

 

Here is some of my specific feedback:

• Are we missing a "Mnemonic" for the read portion of the W1C?
• I agree with your preference for 4 letters... generally, the first pair being a symbol for the access info, the second for the value info.   Should ROO be RORO?  WOO be WOWO?
• Clarify difference btwn empty-grey versus dash.  I thought we don't want to rely on visuals/presentation to carry the semantics? (But i guess this is just an example rendering.)  Does the grey mean unimplemented (access implications), and the dash undefined (value implications)?  I guess i'm asking for definitions for "reserved, unimplemented, undefined".

Here are some possible fringe cases (worry about later... or never):

• What about read-modify-write fields where writeable bits are in an unknown state and should not be modified?  (bad design practice)
• What about a component that has multiple bus interfaces that have different access/visibility into the register set?  Also, SUPERVISOR code could have different visibility over USER code.
• What about when Marketing (phantom ware) or Applications (feature not supported) concerns override the Design?

Best regards,

Alan

---

From: Park Seth-R01164
Sent: Wednesday, May 27, 2009 10:44 AM
To: Semiconductor Information Design Subcommittee
Subject: [dita-sidsc] bitFieldAccess definitions

Attached are the access definitions I used in the pilot and the presentational expectations for each access type.

 

Here are a few comments:

• When possible, if something is read-only, I used a 4-character definition that explains the write behavior. The same is true for write-only.
• No zero ("0") characters are used, so they are not confused for "O"
• RU is used for registers that are reserved for an unknown reason, where the read/write behavior is not known/explained.
• I prefer "RORZ", but there was some "ROZ" instances that our processing supports, but it will be fixed and deprecated.

 

 

 

-seth

 

--------------------------------------------

seth park

information architect

Freescale Semiconductor, Inc.

seth.park@freescale.com

512.895.2463