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

["Spear, Aaron" <aaron_spear@xxxxxxxxxx>]

Hi Anthony,

Some responses inline below:

> >> 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).

A bit of a disclaimer: I am playing a bit of devils advocate here, I
want to make sure that we understand clearly the direction that we are
going and that everyone is on board.  I agree completely that the right
way to do this is to have an abstract API to access target information
regardless of the fact that it came from SPIRIT or a legacy format.  (I
suggested that already somewhere in this thread).  

What I do NOT want to do, is write an implementation of that API that
lives in Java for instance only to find that it is useless to many
people because it is written in java and their debug engines which need
the information are written in C++.  Perhaps this is unavoidable, but my
perception of SPIRIT is that the implementation of the
scripts/java/C++/whatever that does the DOM parsing etc is sufficiently
complex that we do not want to have a lot of separate implementations
floating around.  

>From your experience is this a valid concern?  Does ARM Ltd. have a
single SPIRIT parser, or a number of SPIRIT parsers?  Perhaps I am
overblowing the complexity of a parser (please say so if you think I am)

The reason for perhaps going the route of specifing some other debug
specific format and translating SPIRIT to it would be:

1) The format will by definition be constrained to debuggers needs, and
thus simpler.  This would mean that the implementation of parsers for
the format is easier and the burden of having multiple implementations
(one in GDB, one in some EPL C++ lib perhaps, one in EPL Java)

2) It is completely in our control today.  Because of the fact that
existing SPIRIT files lack some information we might need, the
translators/parsers could be smart enough to prompt to fill in the gaps
(I can hear the groans already, but that will be reality until the world
is on board with us)

All that said, I am personally still in favor of using SPIRIT directly.
I just want to make sure that we all know what we are signing up for,
and that we have a plan in place to actually accomplish the work.  My
real hope here is that once we have an architecture clearly defined for
the parsing and the interfaces that are over the top of it, that we can
find some company(s) willing to donate some code as well (or again,
maybe it isn't all that complex?)

cheers,
Aaron

    
> > 
> > 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.
> 
> 
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>