dita-sidsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita-sidsc] Follow-up: handling multiple instances/instanceBase
- From: "Ratliff Alan-R68672" <alan.ratliff@freescale.com>
- To: "Semiconductor Information Design Subcommittee" <dita-sidsc@lists.oasis-open.org>
- Date: Mon, 29 Jun 2009 10:50:06 -0600
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
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
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
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.":
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
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
If it's unclear, we
might want to schedule a brief interim call so that the official call is
productive.
-seth
park
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]