Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-dd-dev] How do you want to use target descriptions?

Hi Ted,

I think that I will likely start creating something that people can play
with to get some more feedback.  I am going to poke around a bit and see
if there are any companies using SPIRIT right now that would be willing
to contribute some Java code to read SPIRIT files.  (hint hint)  Next
step would be creation of an "target file importer" that read SPIRIT
files into data structures, and then a simple "target view" plug-in that
shows a tree with details of a target, and is a demonstration of how to
use the new target interfaces.

cheers,
Aaron 

-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Williams, Ted
Sent: Wednesday, May 24, 2006 9:30 PM
To: Device Debugging developer discussions
Subject: RE: [dsdp-dd-dev] How do you want to use target descriptions?


hi Aaron,

The "SPIRIT importer" sounds good. I'm uneasy with the two stage
approach, but I don't claim to understand the details well enough, yet.
Are you planning to code the initial version of the library? ;) I'm
working on a gdb prototype built on top of an osgi/async/expression
framework we plan to contribute soon. At the moment, I'm mainly
interested in access to register details. Something more than a hack,
but still experimental, would be great. 

ted


-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
Sent: Wednesday, May 24, 2006 12:44 PM
To: Device Debugging developer discussions
Subject: [dsdp-dd-dev] How do you want to use target descriptions?

Hello everyone,

I wanted to kick up another thread to solicit some thoughts on what we
should DO with target description information.  It seems that from a
requirement standpoint, what I have proposed seems to more or less
address everyone's needs.  The next steps are
1) extending SPIRIT such that everything we need is there
2) actually figuring out what DSDP wants to have in place as far as an
architecture to USE this information.

Regarding use of SPIRIT info:

>From what I gather, in the EDA world vendors do one of a couple of
things with SPIRIT format files.
1) They use XSLT scripts or other custom translation utilities to
transform SPIRIT files into some other format that they use internally.
They then read those files into some internal data structures that their
tool uses directly.
2) They directly read SPIRIT files into internal data structures that
their tool uses directly.

While it would be compelling to have a degree of separation from the
details of the format (and thus be insulated from changes), My
colleagues in the EDA side of Mentor have told me that many SPIRIT
vendors have run into great pain using the translation approach.  I
don't really have experience one way or another about this.  

At this point, I am kind of thinking that perhaps we should just define
a set of interfaces/data structures that define the target in terms of
our needs, and then write a "SPIRIT importer" that can be used to read
information from SPIRIT files into these data structures.  Conceivably
then other vendors can write importers for their legacy file formats
into these same data structures as well.

The data structures can have objects to represent targets, cores,
address spaces, memory maps, registers, peripherals, bit fields, etc.
These objects all have a set of attributes (ISA's and such on cores).
More or less an object representation of what I have in the current doc
at http://wiki.eclipse.org/index.php/DSDP/DD/Spirit

Issues or thoughts about this approach:
1)  I wonder if it would be better to have a less rigid description of
targets (not a fixed hierarchy).  In particular, I am relatively
confident that the model that I see in my head will work fine for
current RISC's and DSP's, but describing a target that is perhaps not a
traditional processor (an FPGA?) might be cumbersome.  Still, you have
to have the knowledge somewhere.

2) This is pretty low level.  Do we need "categories" of targets?  I am
guessing that the link in the RSE to debugging is going to have to
leverage these descriptions somehow (and produce the interfaces for a
debugger to use when starting to debug)  Not all debuggers will need
this sort of level of detail.

thoughts on this?  Sure why not?

Aaron

--
Aaron Spear
Debug Tools Architect/Staff Engineer
Mentor Graphics



_______________________________________________
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


Back to the top