RE: [dita-sidsc] bitFieldAccess definitions/revisited

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.



512.895.2463