[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tm-dev] scope of target descriptions
|
Hello all,
Per the TM call today, this is a reposting/cross posting. Descriptions
of targets is something that is obviously not just related to device
debugging, but is part of the charter of the TM project as well. In
general a target can span many things: remote Linux/AIX/Windows/etc
server, embedded RTOS via Ethernet, bare iron core via JTAG, the host
workstation, etc. To date, the target description discussions that I
have been trying to facilitate discussion about revolve around low level
target details. Cores, bits in registers, memory maps and such. (see
requirements doc on this page:
http://wiki.eclipse.org/index.php/DSDP/DD/Spirit , and the many threads
on the dd list related to target descriptions or SPIRIT)
I am curious what thoughts there are about the need for a more
generalized description of targets, where an "embedded" target is
perhaps only one type of target. It would seem to me that we need some
repository of target description factories, and from it we can get
descriptions of different types of targets where the information is
specialized to the type of target. You can for example have different
"views" of the same target. On one hand, debugging a processor with a
JTAG probe that happens to be running Linux you may see a flat memory
map and all peripherals. For a user level Linux application via an
agent, for all intents and purposes you see a completely different
memory map and limited set of registers. So obviously there must be
different target descriptions for these different connection methods.
regards,
Aaron
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Tuesday, May 30, 2006 11:10 AM
> To: Device Debugging developer discussions
> Subject: 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
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
