2007-10-24 & 2007-11-07 minutes approved

["Beims Bob" <bob.beims@freescale.com>]

Seraphim;
 
I can't figure out how to change the status of the 2007-10-24 &
2007-11-07 minutes from draft to approved. Perhaps since you posted
them, I don't have permission to do that?

Regards,
Bob


-----Original Message-----
From: Beims Bob 
Sent: Wednesday, December 05, 2007 9:07 AM
To: dita-sidsc@lists.oasis-open.org
Subject: [dita-sidsc] 12 November 2007 teleconference minutes draft

SIDSC;

I apologize the last-minute submission of the previous minutes.
(Seraphim, do you use a special widget to create the HTML files, or is
that something built into the OASIS infrastructure that I'm not aware
of?)

Regards,
Bob

This e-mail, and any associated attachments have been classified as:
 [X] Public
 [ ] Freescale Semiconductor Internal Use Only  [ ] Freescale
Semiconductor Confidential Proprietary

________________________________________________

Minutes (DRAFT)

12 November 2007 - OASIS DITA Semiconductor Information Design
Subcommittee

Roll Call

Bob Beims
Duane Becker
Jeremy Ralph

We have quorum (3 of 5 voting members)

1. Review minutes from prior two meetings (10/24 and 07/11). Approved as
posted.

2. Action Items review

#0038 - Bob to disambiguate the names in the register element worksheet.
Completed, and the result was used by Seth Park to create the prototype
structure @
http://www.oasis-open.org/apps/org/workgroup/dita-sidsc/download.php/260
84/sidsc-component-rev1.xml

A short discussion ensued regarding the desire on the part of IBM to see
the register element structure continue to use unique names for all
elements, as that maps the most effectively to how legacy content is
normally represented in FrameMaker MIF files.

Further discussion followed regarding how someone with no commercial XML
tools can dive in and get started with creating and processing DITA
content. The DITA Open Toolkit was suggested, obviously; however it was
noted that this only provides the processing pipeline, not an authoring
environment. It was suggested that there are several tools (oXygen,
XMLmind, Serna, etc.) that offer free limited time trial downloads that
could be used. dita.xml.org was referenced as a good starting point to
look for options.

#0043 - Start a wiki page for collection of signal description elements.
Completed, but not in use, as yet.

A short discussion ensued regarding what we mean by "signals" in this
case. Bob suggested that the intent is to follow a path very similar to
what we did for the register description elements: identify all of the
little pieces of information that we all provide to customers in
documentation. Basically, what must be described and understood by
customers in order to design their system. A distinction was made that
this would be limited to the logical function and basic characteristics
of the signal, but not the detailed electrical specifications. Examples
given by Duane Becker:

Name, description, direction, driver type (push-pull, open-drain, etc.),
perhaps the voltage source, differential, pin number, multiplexing
modes, bus range, MSB designation, etc.

The question arose as to how much we can borrow from the work done
within the IP-XACT schema to start identifying signals. The issue of
internal versus external signals also came up; since in many cases we
will be documenting IP blocks that may have no signals that will ever
reach the outside of an SoC, and yet they must be described in order for
an SoC integrator to utilize the IP block. It was agreed that we must
build a data model that comprehends the difference between internal and
external signals. Additionally, each member company must also be able to
assign attributes to elements in such a way that information
confidential to a company may filtered out of an information set in a
secure manner before delivering the information to partners external to
the member company. And, of course, that filtering mechanism must not
break the validity of the XML with respect to the DITA DTD / schema.

The discussion then turned to how this info might be reused outside of
the documentation model? For example, how might the signals-to-pin
mapping dependencies be coded in the DITA information set in such a way
that it can be extracted and transformed into a format used by a design
automation tool such as simulators, configuration aids, verification
tools, etc.

Final clarification was made with respect to the term "signal" and
"pin"; where "signal" denotes the logical and functional descriptions of
signals [see:
http://en.wikipedia.org/wiki/Signal_%28electrical_engineering%29], while
"pin" denotes the physical instantiation of an electrical interface
between an SoC and its external environment (also called "pad", "ball",
"bump", etc.). Bob also suggested that the IP-XACT schema for bus /
signal information is closely related to the "signal" information we'll
be capturing in DITA, while the RosettaNet / IEC-61360 schema is more
closely related to the "pin" information we'll address in future work.

Bob took a follow-on action to create a spreadsheet similar to the
register element worksheet and post it for on-going work on signal
element definitions. It was agreed that the wiki may not be the best
mechanism for collecting these element tables. Duane strongly suggested
using the "check-in/out" mechanism we've used for the register data
sheet so that we don't have to re-work a lot of this info. Duane
committed to get the IBM contribution in place by Monday (26 Nov),
assuming Bob gets the placeholder spreadsheet in place by then.

Jeremy indicated that they've been very focused on the register map
stuff to date, and isn't sure he'll have much bandwidth to address the
signal-level information in the next few weeks. But he'll see what he
can do.

3. Other business discussion

Duane Becker (IBM) has been facing challenges regarding having employees
of a member company review SC work and provide feedback through their SC
voting member. Duane will re-submit his finding through the SIDSC mail
list for further scrutiny.

4. Discussion of upcoming meetings

Everyone acknowledged that the next few weeks are going to be extremely
busy for everyone with holidays, and that SC work may slow down a bit
until January. The possibility of canceling the 12/19 teleconference was
raised, and will be discussed on the 12/05 teleconference.

5. Adjourned at approximately 10:40 AM CST.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php