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