Comments on DITA TC SIDSC Charter

["Jeremy Ralph [DITA SIDSC]" <jralph-sidsc@productive-eda.com>]

There are some additional patterns which I think should be considered as
part of the goals.  These include: 

1) Component Data - the hierarchy of blocks that define the chip.  This
would include IP components, sub-systems, and the type of information that
is often captured in a block diagram.

2) Programmers' API Data - the view of the chip at a software level.  Often
complex chips will ship with a software driver that abstracts the hardware /
software interface.  From the software perspective, the information relating
to the functions, data structures, classes and methods is how the hardware /
software interface is defined.  Documentation of C/C++ API's is often
auto-generated by Doxygen (www.doxygen.org/) which produces HTML, XML and
other formats. 

3) Product Family Data - the information that is common across all chips in
the product family and the information that is specific to a particular
product.

As part of researching data patterns it might be good to create a list of
links to publicly available data-sheets, from a variety of different
companies and applications domains.  This would help to ensure that we are
addressing the concerns of the entire semiconductor industry rather than the
specific requirements of the DITA SIDSC participants. 

As was mentioned during the last call (by Susan?), I think there should be
some prioritization of the goals.

Best Regards,

--
Jeremy Ralph

PDTi
 > http://www.productive-eda.com 
SpectaReg 
 > Spec-down code and doc generation for register maps
 > http://www.productive-eda.com/SpectaReg