RE: [dsdp-dd-dev] SPIRIT vs a new standard XMLschema?(wasDebugmodeland G

["Gaff, Doug" <doug.gaff@xxxxxxxxxxxxx>]

Hi guys,

>From Wind's perspective, we read our current data files from our C++
debugger engine, and we'll likely have to build SPIRIT data file
translators like everyone else.  Eventually, I'd like to read those
files directly, but I'm sure we'll have to translate for some period of
time until we can change the debug engine.

I don't see this as a big issue right now, though, and I think writing
some tooling (editing, parsing, rules checking) in java seems like a
reasonable first step.  Anthony, perhaps you can provide more detail on
how the Tight Generator Interface is going to work.  Perhaps that will
help us down the road for the non-java cases.

Anthony, I'm glad to hear that you'll have something to contribute soon.
Perhaps you can put a couple of teaser screen shots in the SPIRIT
section of the DD Wiki.  :)  Also, I'd recommend contributed to open
source sooner rather than striving for perfection or completeness prior
to contribution.  This allows others to see what you're doing and might
also give you some help.  (Incidentally, we are struggling with this
very thing on our debug model contributions.)

Aaron, regarding defining debugger extensions to the SPIRIT format, I
think I've lost the thread for what you need next from folks (sorry).
Perhaps you can restate that for everyone on this list.

Doug G


> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Friday, June 16, 2006 11:11 AM
> To: Device Debugging developer discussions
> Subject: RE: [dsdp-dd-dev] SPIRIT vs a new standard
> XMLschema?(wasDebugmodeland GDB?)
> 
> Hi Martin,
> 
> Thanks for the insight into TI's usage.  I think that this kind of
> information about how and where people will really use this info is
> crucial to creating something really useful.  Your solution sounds
> nearly identical to what my company is doing as well in our debugger
> (sounds like we need a standard!).
> 
> Can you explain a bit more background about the naming convention
> problems you have seen?  Is this perhaps another area where a change
in
> the SPIRIT specification/standard is necessary, or is it just
outlining
> the need for some kind of possible SPIRIT add-on that might be a
> database/registration of different components of some kind?
> 
> cheers,
> Aaron
> 
> 
> > -----Original Message-----
> > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> > Swiezawski, Martin
> > Sent: Monday, June 12, 2006 8:10 AM
> > To: Device Debugging developer discussions
> > Subject: RE: [dsdp-dd-dev] SPIRIT vs a new standard XML
> > schema?(wasDebugmodeland GDB?)
> >
> > Aaron,
> > I have been following the discussion between you and Daniel.
> > TI is currently using custom XML format that meets our
> > debuggers' needs. We have a combination of XSLT & scripts
> > that perform initial translation from either SPIRIT or some
> > other format into debugger's XML format.
> > However, resulting files need to be tweaked a bit. There was
> > couple of reasons that caused us to move in this direction.
> > A) HW specifications did not contains CPU native registers B)
> > non-standard names to identify CPUs were used. Second issue
> > is not that critical for single CPU devices, however it is
> > important for multi-processor devices, where you need to know
> > whether peripheral X is accessible and visible through CPU
> > 1 or 2.
> >
> > We have organized our debugger XML database to have generic
> > peripheral files that are then included by device specific
> > files. We are also using a slightly modified version of an
> > XML parser that allows us to handle couple of tags in a
> > special way. E.g. specify in device file included
> > peripherals' base address. Our backend debugger(C++)
> > currently does the parsing and provides register information
> > to clients.
> >
> > In my mind, ideal solution would be to use SPIRIT. There
> > would be a standardized component that reads that data and
> > provides it through an API. Folks could then decide where
> > this component needs to be plugged into. However, a big
> > hurdle that I see is standardized naming conventions to be
> > able to identify cpus, peripherals, registers and match this
> > with whatever the debugger is expecting.
> >
> > Martin
> >
> >
> > -----Original Message-----
> > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > Sent: Friday, June 02, 2006 4:13 PM
> > To: Device Debugging developer discussions
> > Subject: RE: [dsdp-dd-dev] SPIRIT vs a new standard XML schema?
> > (wasDebugmodeland GDB?)
> >
> > Doug,
> >
> > I have posed a bunch of questions recently that perhaps are
> > buried in the discussion, but I think that the most pressing
> > one to answer is perhaps where people see this info being
> > used.  The reason that I think this is important to answer
> > now is that it will impact what is useful to have as far as
> > tooling goes.  In effect, the questions is whether or not it
> > is profitable for us to write java XML parsing code specific
> > to SPIRIT or not.  I know that you guys (Wind) have a
> > debugger architecture similar to ours in that you have a
> > native debugger back end that your Eclipse front end
> > communicates with.  If you need the info in your back-end,
> > then either you need to parse it in the back end as well as
> > the front end, or you need to parse it in the front end and
> > push it through to the back. (make sense?)
> >
> > I do think that regardless of the outcome of the discussion
> > above, we need to start identifying the extensions that are
> > needed in the SPIRIT schema and creating tools that use them.
> >  I think that SPIRIT is the only real hope of getting info
> > from the semiconductor vendors in a format that is useful.
> > What we then do with that info (use it directly or translate
> > it to another format that we use directly) is another discussion.
> >
> > Aaron
> >
> > > -----Original Message-----
> > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Gaff, Doug
> > > Sent: Friday, June 02, 2006 1:26 PM
> > > To: Device Debugging developer discussions
> > > Subject: RE: [dsdp-dd-dev] SPIRIT vs a new standard XML schema?
> > > (wasDebugmodel and GDB?)
> > >
> > > This is somewhat related to my question to Anthony about how to
> > > proceed.
> > >
> > > My opinion:  we should continue to define what we think the
> > SPIRIT for
> > > debug schema looks like, implement some initial tooling
> > based on that,
> > > and then let Anthony and Aaron take it back to the Consortium for
> > > comment.  Minor revisions to our ideas should be easy to
> > adapt to and
> > > will be necessary until an official SPIRIT release anyway.
> > >
> > > Doug
> > >
> > > P.S.  Welcome to the DD project Daniel.  Thanks for joining the
> > > discussion.
> > >
> > > > -----Original Message-----
> > > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-
> > > > bounces@xxxxxxxxxxx] On Behalf Of Daniel Jacobowitz
> > > > Sent: Friday, June 02, 2006 2:07 PM
> > > > To: Device Debugging developer discussions
> > > > Subject: Re: [dsdp-dd-dev] SPIRIT vs a new standard XML
> > > schema? (was
> > > > Debugmodel and GDB?)
> > > >
> > > > On Fri, Jun 02, 2006 at 11:01:13AM -0700, Spear, Aaron wrote:
> > > > > I am still hoping to solicit some other opinions on this
issue,
> > > perhaps
> > > > > from folks like ARM Ltd. Who are users of SPIRIT on the hw
> > > development
> > > > > side of things with their ESL tools and such, and then have
been
> > > talking
> > > > > about using it for debug as well.
> > > > >
> > > > > The question is really should we use SPIRIT directly or a
> > > decoupled
> > > more
> > > > > debugger centric standard?
> > > >
> > > > Well asked.  I'll await opinions with interest.
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > CodeSourcery
> > > > _______________________________________________
> > > > dsdp-dd-dev mailing list
> > > > dsdp-dd-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > > _______________________________________________
> > > dsdp-dd-dev mailing list
> > > dsdp-dd-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > >
> > _______________________________________________
> > dsdp-dd-dev mailing list
> > dsdp-dd-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > _______________________________________________
> > dsdp-dd-dev mailing list
> > dsdp-dd-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> >
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev