RE: [dita-sidsc] Follow-up: handling multiple instances/instanceBase

Thanks for your response, Seth.  

I think we're getting 
closer to a common understanding....

 

Re: Slide 
6:

Seth says: "Do you think we need to support 
pattern-less register repetition similar to how we handle component 
repetition?"

Alan says: "No, I think your reasoning is sound here as 
I read your email below.  I finally think I understand my confusion with 
Slide 6:  I was reading "UARTA & UARTB" as two instances of a generic 
UART component, but you are talking about a repeating register within a single 
component instance.  Slide 6 is still covering your case #1:  "1.Multiple instances of registers (must have a 
pattern)".  Right?  If so, nevermind.  
:-)  

 

Re: "instanceOffset" on 
slides 7 &8 
...

To me it 
makes more sense to talk about an "instanceBase" 
instead of an "instanceOffset" variable.   
At least I don't think about component instances being placed in the system 
memory map relative to each other.  (I 
mentioned this in my earlier feedback 
below.)

 

Missing Case #3?:

Can we handle the case #3 
"1.Multiple instances of registers within components that 
occur more than once " you state on Slide 2?  I think your proposal can handle it, but I don't 
see the "collapsed" use case 
explicitly in the presentation.  I'm talking about handling the TPMxCnVH 
case where "x" represents multiple component instances and "n" represents a 
repeating register within a given component.   You don't have 
to update the presentation; I'll be satisfied with a "yes."

 

 

Also, here's a restatement of my general concern that I 
think you already understand...

 

Full-frontal components (or... This component 
parameter has been rated "X" for "undecided.")

I 
wanted reassurance that the structure of the component itself won't prevent us 
from showing all the adjustable "knobs & switches" within the component 
because

we will need to be able to satisfy the "system 
architect/integrator" audiences that will need to know all of the potentialities 
of the component before making a decision on a specific 
instance/configuration for their "higher-level" design.  In other words, we 
should not be limited to showing only specific instances.

My concern was that the proposed instance structures 
would impose too many constraints on the generic component information, but I'm 
OK if you're confident we can get this use case to 
work.  :-)

 

Thanks again for all of your great work on the 
proposal... and in general.

 

Best regards,

Alan

From: Park Seth-R01164 
Sent: 
Wednesday, June 24, 2009 3:29 PM
To: Semiconductor Information Design 
Subcommittee
Subject: RE: [dita-sidsc] Follow-up: handling multiple 
instances/instanceBase

Hi Alan. Thanks for your thoughts!

 

Slide 6:

UARTA and UART B are instances of a UART component. For 
multiple instances of components, you use <instanceParameters>, which is 
slightly different from <dimension> (dimension is only for registers). It 
is assumed that component instances will be small in number and will 
not conform to a pattern. That's why you provide an offset and 
qualifier for each instance as a comma-delimited string in the corresponding 
elements.

 

Register repetition can be very large in number and 
will likely have a linear pattern (only integer values are allowed). If there is 
no linear pattern, the amount of effort required to designate an offset and 
qualifier for each instances would be burdensome.

 

Do you think we need to support pattern-less register 
repetition similar to how we handle component repetition?

 

Other comments

Please see http://www.oasis-open.org/apps/org/workgroup/dita-sidsc/download.php/32841/conref-to-pass-parameters.pdf. 
It shows how parameters stored in the sidsc-design map override elements in the 
component files. I happened to use the <dimension> structure as an example 
of how the proposed sidsc-design map enables us to "parameterize" reusable 
blocks as a series of RTL parameters stored within the component 
reference.

 

We wont be able to use conref-push-replace or keyref 
until DITA 1.2 is released, but the sidsc-design map provides the semantics to 
change the meaning of specific component data depending on the the IC RTL 
parameters.

 

 

Does this cover all of your 
concerns?

 

 

-seth park

From: Ratliff Alan-R68672 
Sent: 
Wednesday, June 24, 2009 9:59 AM
To: Semiconductor Information Design 
Subcommittee
Subject: RE: [dita-sidsc] Follow-up: handling multiple 
instances/instanceBase

Dear Team,

 

Attendance Note:

Unfortunately I have a running conflict with the SIDSC 
meetings now.  And just when I was starting to have time to get passionate 
again....

Here's more feedback.  Sorry I won't be there to 
explain if i'm not making myself clear.

 

Feedback On slide 6 "Publishing 
ramifications.":

  

  
I'm not clear that the scheme will work for a 
  possible UARTA, UARTB and UARTC if the UART blocks are not spaced evenly in 
  the overall system memory map.  Do I understand correctly that 
  <dimensionIncrement> is a single static 
value?

 

More Feedback on where instances 
belong:

  

  
I'm probably missing something but let me try to 
  elaborate on my perspective:  I think instance structures belong 
  outside the scope of the generic component structure.  Embedding 
  instance structures within the generic component implies the instance is 
  subordinate (but it's super-ordinate if that's a word).  
  

  

  
Also, there is a business need to document the 
  generic component in its standalone fully parameterizable glory for internal 
  audiences at least if not external.  So, could the proposed instance 
  structures be ignored or otherwise handled in this case? 
  

Thanks.

-Alan

From: Ratliff Alan-R68672 
Sent: 
Sunday, June 07, 2009 5:28 PM
To: Semiconductor Information Design 
Subcommittee
Subject: RE: [dita-sidsc] Follow-up: handling multiple 
instances/instanceBase

Thanks for the great work, Seth.

Your proposal makes sense, but looking at slides 7 &8, 
regarding the "instanceOffset" variable...

 

To me it makes more sense to talk about an "instanceBase" 
instead of an "instanceOffset" variable.   At least I don't think 
about component instances being placed in the system memory map relative to each 
other.   This approach would also resolve your questions at the bottom 
of slide 8.  Of course it might break other things, but this is my 
perspective.

 

In general, I see needing to use an instance container 
(even if we have just one instance of the component) to inform processing 
and to populate variables inside the generic component 
model.

 

Thanks 
again.

-Alan

 

From: Park Seth-R01164 
Sent: Tuesday, 
June 02, 2009 9:23 AM
To: Semiconductor Information Design 
Subcommittee
Subject: [dita-sidsc] Follow-up: handling multiple 
instances

Just a friendly 
reminder to review the proposed changes for multiple instances of registers and 
components: http://www.oasis-open.org/apps/org/workgroup/dita-sidsc/download.php/32714/usecases-dimensions.ppt

 

If it's unclear, we 
might want to schedule a brief interim call so that the official call is 
productive.

 

 

-seth 
park