[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] WR Boardfile Descriptions
|
Thanks Aaron,
to make access to your document as well as discussions easier,
I've uploaded your text as well as the ZIP archive to the Wiki:
http://wiki.eclipse.org/index.php/DSDP-TM_Hardware_Descriptions_at_ATI/M
entor_2006x02x17
Cheers,
Martin
--
Martin Oberhuber - WindRiver, Austria
+43(662)457915-85
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Friday, February 17, 2006 3:19 AM
> To: Target Management developer discussions; dsdp-dd-dev@xxxxxxxxxxx
> Subject: RE: [dsdp-tm-dev] WR Boardfile Descriptions
>
> Hello All,
>
> To follow up on this discussion a bit, I have put together an
> example of
> our target description scheme that we use for EDGE Developer Suite.
> Attached you will find a zip that contains a number of things:
>
> In our system of things we have three different types of XML files,
> target, core, and peripheral files. They define targets, cores and
> peripherals (wow!). We have gone through a few iterations of things,
> but most everything is the same as it has been for a while.
>
> MyTarget.target: this is the main target file for a particular board.
> This is a pseudo-real example that has a multicore board that includes
> an ARM9 and a MIPS24Kc (sure, why not?). It declares things like what
> cores are on the board, what the memory maps look like for
> the core and
> such. inside of the target file it refers to various core and
> peripherals. I tried to put in some helpful comments that explain
> things in this file.
>
> doc: directory that contains DTD's for the various target
> files, and an
> excerpt of our Eclipse HTML help for the format of the XML files. The
> doc itself really is a reference only, it doesn't' really show you the
> big picture very well. Easiest to understand by looking at the files
> themselves, and then if you don't understand something, look for the
> particular element/attribute in the DTD's or the doc.
>
> More than anything else I hope that this is food for thought for
> everyone. See you next week in Toronto!
>
> cheers,
> Aaron
>
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Monday, February 13, 2006 3:50 PM
> To: Target Management developer discussions; dsdp-dd-dev@xxxxxxxxxxx
> Subject: RE: [dsdp-tm-dev] WR Boardfile Descriptions
>
> Antony,
>
> If you all are going to have someone at the meeting, discussing ARM's
> involvement and experience with SPIRIT would be quite welcome. I was
> planning on giving a quick over view of what Accelerated Technology is
> using for our XML based target description format, and then giving a
> summary of my research into SPIRIT. I am admittedly a newbie
> to it, so
> my experience is limited to what I have read and discussions with my
> hardware colleagues at Mentor. As such, if you guys are able to
> present, I think that would be great.
>
> I think that key thing to take away would be a plan for how we move
> forward. Off the top of my head, it seems that answers to
> the following
> questions would be good:
>
> -What are common needs that everyone has for target definition
> information -How do those needs align with existing standards (e.g.
> SPIRIT) -What is the role of this target definition in DSDP? Do we
> create a utility as a part of the DSDP framework that parses these
> target descriptions and provides services? What components use those
> services, target management?
> -How do we plug-in these target descriptions in a standard way?
> (extension points? plain XML?)
> -What sorts of things do we need to allow to be Vendor specific?
>
> Related to SPIRIT:
>
> Is the extension of SPIRIT for debug use something that you have
> formally proposed with the consortium? Do you have a
> specification for
> your debug specific extensions that can be shared? Do you have an
> existing debugger/tool that is making use of SPIRIT format files
> (RealView?)
>
> thanks!
> Aaron
>
>
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Berent
> Sent: Monday, February 13, 2006 2:28 PM
> To: dsdp-dd-dev@xxxxxxxxxxx; dsdp-tm-dev@xxxxxxxxxxx
> Subject: RE: [dsdp-tm-dev] WR Boardfile Descriptions
>
> Martin, Aaron et al,
>
> As Aaron says, the SPIRIT consortium have, over the past couple of
> years, created a standard (soon to be submitted to IEEE) for
> describing
> hardware IP (particularly SoCs, but also boards etc.) in XML. This
> standard effectively provides machine readable data books of the IP
> components and systems. While this standard, in origin,
> targets hardware
> design tools, SPIRIT descriptions are quite a close fit to
> the hardware
> target description needs of debuggers and emulators.
>
> Over the last 9 months or so, we, at ARM, have been looking at making
> use of SPIRIT within our debug toolchain, and it has become
> apparent to
> us that there would be significant advantages to all concerned (IP
> vendors, debugger vendors, hardware design tool vendors, and hardware
> and software developers) if SPIRIT were to become the standard for
> describing hardware to debuggers. As such we have proposed that the
> scope of SPIRIT should be formally extended to include its use for
> debug. We have also had some initial discussions on this with a number
> of our partners, and have validated that there is wide
> agreement on the
> need for such a standard.
>
> We would now like to propose that DSDP should look at using SPIRIT as
> its standard for describing target systems. While I am
> personally unable
> to attend next week's meeting, we do hope to have someone at the
> meeting, and would welcome the opportunity to present our proposal in
> more detail to both the Device Debug and Target Management subgroups.
>
> - Anthony
>
> --------------------------
>
> Anthony Berent
>
> ARM Ltd
>
> +44 1223 400763
> > dsdp-dd-dev] RE: [dsdp-tm-dev] WR Boardfile Descriptions
> > From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
> > Date: Wed, 8 Feb 2006 21:30:32 +0100
> > Delivered-to: dsdp-dd-dev@xxxxxxxxxxx
> > Thread-index: AcYEuBnWPAimGiM1RV2+9SboHnyGtgnbUn/gAAcgyjAAE82jYA==
> > Thread-topic: [dsdp-tm-dev] WR Boardfile Descriptions
> >
> > Hello Aaron,
> >
> > I'm forwarding your E-Mail to the dsdp-dev and dsdp-dd-dev mailing
> > lists.
> >
> > I'm glad you bring up the issue of standardized hardware
> descriptions
> > again. Yes, this will definitely be a point for discussion
> in Toronto;
>
> > Doug Gaff also got some contact at ARM who's saying that they are
> > working on some standardized hardware description format.
> > Doug expects to have more info by the time of the Toronto
> meeting.
> >
> > I'm going to update the TM agenda accordingly on the Wiki;
> I'd suggest
>
> > we do it on Thursday in the DD/TM joint session.
> >
> > As you seem to be especially interested and involved, it would be
> > great if you could go ahead and drive the discussion
> further. Is it OK
>
> > if I put your name as presenter for the slot on hardware
> > descriptions?
> >
> > To all others: any additional information, existing formats in use,
> > and other preparation we can bring to Toronto will certainly be
> > helpful.
> >
> > Thanks,
> > Martin
> > --
> > Martin Oberhuber - WindRiver, Austria
> > +43(662)457915-85
> > dsdp-tm-dev-bounces@xxxxxxxxxxx wrote:
> >> A little more info: I talked to a colleague of mine in
> Mentor's SoC
> >> division about this, and he advised me that we really should look
> >> into what is happening with the Spirit Consortium.
> >> http://www.spiritconsortium.com/ They are apparently creating and
> >> pushing standards for description of hardware IP using an
> XML schema.
> >> My friend said they are planning on submitting the
> standard to IEEE
> >> this next summer as well.
> >>
> >> Perhaps it may be possible to join a Spirit working group
> and piggy
> >> back our target description efforts. Or as Martin
> suggested before,
> >> perhaps we can create conversion tools from the Spirit schema to
> >> something we decide on as a standard. It sounds like we
> need to get
> >> a cohesive idea of what we need to see if there is a fit.
> >>
> >> cheers,
> >> Aaron
> >>
> >> -----Original Message-----
> >> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> >> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> >> Sent: Tuesday, February 07, 2006 2:23 PM
> >> To: Target Management developer discussions
> >> Subject: RE: [dsdp-tm-dev] WR Boardfile Descriptions
> >>
> >> Martin et al,
> >>
> >> A while back you posted this, and I would like to pick the
> discussion
>
> >> back up. Is this a topic that others would like to
> discuss at the TM
>
> >> meeting in Toronto? I have had the intention since you originally
> >> posted of contributing documentation and some samples of
> the target
> >> definition files we use as food for thought as well. I
> will try and
> >> post them in the next week or sp. I have personally spent
> many mind
> >> numbing hours transcribing data sheets that someone at the semi's
> >> spent many mind numbing hours creating, and would really
> like to see
> >> something happen. (anything! please!)
> >>
> >> Are there any hardware folks on this thread that can speak to the
> >> existence of relevant standards in the EDA world? I am sure they
> >> have standards for specifying to the N'th degree what
> sorts of access
>
> >> and timing restrictions there are for a memory mapped
> peripheral for
> >> example, but are there "system level" hardware descriptions that
> >> would could fit the needs of debugger vendors? (or could
> be extended)
> >>
> >> Information such as:
> >> -cores on a target, scan chain id's etc -native registers
> in the core
>
> >> (access restrictions, sizes, processor modes that they are visible
> >> in, etc) -address spaces -memory maps for those address spaces
> >> (access restrictions on given regions, e.g. flash versus
> RAM) -memory
>
> >> mapped peripherals (location in memory space, registers it
> >> contains) etc
> >>
> >> regards,
> >> Aaron
> >>
> >> --
> >> Aaron Spear
> >> Debug Tools Architect
> >> Accelerated Technology a Mentor Graphics Division
> >> aaron_spear@xxxxxxxxxx
> >> 303-679-8457
> >>
> >>
> >> -----Original Message-----
> >> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> >> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber,
> >> Martin Sent: Monday, December 19, 2005 9:20 AM
> >> To: Target Management developer discussions
> >> Subject: [dsdp-tm-dev] WR Boardfile Descriptions
> >>
> >> Hello,
> >>
> >> In the TM session of the DSDP meeting in Chicago, we came
> to a point
> >> where we noticed that TM wants to provide a common platform for
> >> describing the targets (hardware) we are working on.
> >>
> >> Currently, every vendor is doing their own hardware descriptions,
> >> typically by XML or some other files... they all have to read the
> >> specs from silicon vendors, and create their own file formats.
> >> That's a lot of wasted work.
> >>
> >> We are hoping that at some point it might be possible to create a
> >> uniform "standard" file format, or at least provide some
> converters
> >> between various file formats. Ideally, then silicon vendors could
> >> provide their specifications in the uniform format (or something
> >> convertible). Silicon vendors could become the "experts"
> for hardware
>
> >> descriptions, users could get patches/updates directly from them...
> >> lifting off a lot of work from tool vendors like us.
> >>
> >> As a first step, I'm attching a sample and description of
> the board
> >> file specification that Wind River is currently using.
> >>
> >> I'd hope that other companies could follow and put their
> samples or
> >> descriptions to the table, such that we can get a feeling of what
> >> features are required from a "unified" format, and find out future
> >> steps to take.
> >>
> >> Thanks,
> >> Martin
> >>
>
> -- 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-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
