RE: [dsdp-dd-dev] SPIRIT vs a new standard XML schema? (was Debug modela

["Anthony Berent" <Anthony.Berent@xxxxxxx>]

Spear, Aaron wrote:
> I changed the subject line to reflect the gist of the discussion a
> bit more accurately as it is evolving... 
> 
>> -----Original Message-----
>> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
>> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel
>> Jacobowitz Sent: Friday, June 02, 2006 10:21 AM
>> To: Device Debugging developer discussions
>> Subject: Re: [dsdp-dd-dev] Debug model and GDB?
>> 
>> I'm happy.  When I first encountered the description of what you were
>> doing, it seemed that we were coming from very different directions,
>> but a little communication is showing that we're really moving the
>> same way!
> 
> I hope so.  I don't want this to be a doomed effort from the start! 
> If it is not going to work for the key players here architecturally
> due to the nature of how their debuggers are set up, then we need to
> rethink it.  The goal is widespread adoption and a low barrier to
> entry.  We had for instance talked about creating as a part of DSDP
> free editors for these files so that even small fry board vendors
> could put together descriptions of their boards that will then work
> with any debugger that supports their chip architecture.

I have done some preliminary work on such an editor for SPIRIT, based on
the customizing the Eclipse XML editor. It is not yet in a fit state to
show to anybody, but I would expect to be able to contribute an initial
version to DSDP later this year.
        
> 
>> I thought I'd seen you say that relying on transformations of the
>> SPIRIT data had been a major source of problems, though?
> 
> Well, that information came from a colleague of mine in the Mentor
> EDA world.  They are of course heavy duty consumers/generators of
> SPIRIT information, using all that stuff that we will never use in a
> debugger.   
> I think that the issue there is the fact that there is possibly a
> massive hierarchy of XML files containing various peripherals all
> connected to various buses and such.  When you try and transform that
> into another format that has a different sort of hierarchy and
> different layout of information, you get into trouble using scripts. 

It depends what you think the limitations of scripting are. You could
certainly get these sort of problems if your script is only able to look
at one SPIRIT file at a time, or is only able to process them
sequentially. In certain scripting languages one can go well beyond
this, and make use of, for example, DOM parsers to process the SPIRIT
files. An example of this sort of script is the SPIRIT semantic checker,
which is written in TCL, and is included in the SPIRIT 1.2 release. This
reads a library of SPIRIT files, and does various checks on them. Some
of these checks can involve using information from up to five separate
files. 

> I have not really done any experimentation around this yet so see
> what the most viable way of doing this is.  It may be that someone
> should just write a dedicated translator from SPIRIT to another XML
> format, so that the translation is done in code and thus anything is
> possible.  Then various tools can write libraries that work on this
> standard format in whatever language, and that work can be shared.

I don't understand what you are proposing here. What XML format would it
translate to? Would not a better route be to have a SPIRIT reader with a
well defined API at a reasonably abstract level? This could then be used
either directly in debuggers, or in translators to other, proprietary,
formats (XML or non-XML).
   
> 
> 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? 

In ARM at the moment we are converting from SPIRIT to our existing
formats, simply because this is the easiest way of working with legacy
code. To do this we are using libraries (written in C++) rather than
scripts, simply because this fits best with our products and our way of
working. In time I expect us to move over to using SPIRIT as our native
debug target description format.  I would, however, always expect there
to be a format independent API between the SPIRIT reader and the actual
debugger.

If we were not constrained by having to work with legacy code we would
probably go straight to using SPIRIT natively.

Why SPIRIT? For me the main reasons are:

1 - It is there. Agreeing standards takes a lot of work, and having a
good base to work from (and a structure to work in) is a major
advantage. What is more it is supported by the people who provide the IP
(including us) and by EDA and ESL vendors (again including us, but also
including some much bigger players in these fields). This means that it
should be easy to create the SPIRIT descriptions as part of the design
process.
2 - It contains much of the information needed by debuggers. In
particular it describes the connectivity between components, and hence
the access to the debug hardware of the components; and the memory maps
can be calculated from a SPIRIT description.
3 - It is scalable to large systems with multiple processors. There are
two reasons I say this:
    A) It separates component instances from component types, hence
simplifying the description of duplicate components, and making reuse
much easier.
    B) In our old target descriptions (BCD files) if two processors in a
system have different memory maps then you need two descriptions of the
system. In SPIRIT, since the memory maps are inferred from the component
and bus structure, a single description can describe all the memory
maps. 

No pre-existing standard is, however, ever going to be a perfect fit
with a new application. SPIRIT, in particular, is not currently designed
to describe internal registers, and it cannot describe things like JTAG
instructions. It does, however, seem a good base to work from, and since
it is still evolving we have the ability to influence its development. 

- Anthony

--------------------------

Anthony Berent

ARM Ltd

+44 1223 400763

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.