[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] RE: [dsdp-tm-dev] Target/Boarddescriptionrequirements: your thoughtsrequested
|
Aaron,
Thanks for the reply. I don't have commit rights. Doug, will you
upload the document?
See more comments below.
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> Sent: Monday, April 10, 2006 8:51 PM
> To: Device Debugging developer discussions; Target Management
> developer discussions
> Subject: RE: [dsdp-dd-dev] RE: [dsdp-tm-dev]
> Target/Boarddescriptionrequirements: your thoughtsrequested
>
> Hi Felix,
>
> some more input inline below. Also, could one of you that has commit
> writes on the Wiki post this updated version of the doc?
> ftp://ftp.mentor.com/pub/outgoing/DSDP_target_definition_requi
> rements.do
> c (still working with the legal dept you know. What fun!)
>
> This update contains comments from Anthony Berent from ARM on
> each item
> that details what is in SPIRIT right now and what would have to be
> added. This version also fixes my embarrassing misspellings
> (I typed it
> very fast very late one night)
>
> cheers,
> Aaron
>
>
> > -----Original Message-----
> > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Burton, Felix
> > Sent: Monday, April 10, 2006 7:33 PM
> > To: Target Management developer discussions; dsdp-dd-dev@xxxxxxxxxxx
> > Subject: [dsdp-dd-dev] RE: [dsdp-tm-dev] Target/Board
> > descriptionrequirements: your thoughtsrequested
> >
> > Aaron,
> >
> > Sorry for the late response. Here are my questions/comments:
> >
> > 3.1: Does Memory Mapped registers include I/O ports like 68k
> > use to have? I assume the I/O space should be considered to
> > be another memory space, right?
>
> yes, I/O space like in 68k or x86 for that matter would be another
> separate address space. Registers would be defined relative to some
> base address (which itself contained the address space reference some
> how)
>
> > 3.2.10: Having bitfield be below registers does not allow
> > bitfields to cross multiple registers. What if bitfield are
> > made a top level notion that can refer to one or more
> > registers? Another solution would be to be able to create
> > "virtual" registers from one or more physical ones.
>
> Hmm. I had not considered that. In most cases that I have seen it is
> most intuitive to think of the bitfield as a child of a
> single register.
> Are you thinking of a particular example where you have a
> bitfield that
> spans multiple registers? would it be something like a 64
> bit bitfield
> that was contained in two 32 bit registers? Or some weird
> architecture
> that decided to map a 16 bit bitfield across multiple registers? (most
> likely a backwards compatibility hack).
I don't have a particular example of a bitfield spanning multiple
registers, but I would not be surprised to see it. I was thinking about
the PowerPC timer registers TBU/TBL when I write this.
> One of the other things that I had in there for bitfields in 3.2.10.4
> was "Post-read/Pre-write formulas". My intention was to deal
> with cases
> where it is for example most intuitive to view a value as a 32 bit
> address when in reality the bit field is the top 17 bits of
> the address
> for example. In this case the post read formula would left shift the
> value, and the pre-write formula would mask and then right shift the
> value. perhaps this concept could be extended to include where the
> value is read from (as opposed to having it implied since it
> is a child
> of the parent register.
>
> My gut reaction is that I like the idea of the virtual registers and a
> bit field being a child of it. You could still do whatever weird
> masking and shifting on the bits you wanted in the bit field formula.
> Of course we would need the same sort of mechanism, a formula that is,
> to construct the virtual register from constituent parts as well. Hmm.
I like this. Seems very flexibile.
> > 3.3.1: I think this should be moved to the common section and
> > be optional.
>
> Yes, it should be optional, that was an oversight. However,
> I am a bit
> confused why the compiler/assembly to register id string mapping would
> be shared between "native registers" (maybe better to call them "core
> registers"?) and memory mapped registers. have you seen
> compilers that
> generate register indexes in dwarf info or the like for memory mapped
> registers? Seems like they wouldn't bother but would create absolute
> addresses in the debug info for them...
I have not seen this yet. I am just trying to keep this general and
flexibile where it does not add cost/overhead. If you feel it would add
cost/overhead I am open to keep it the original way.
> >
> > 3.4.1: Can there be multiple "base address"?
>
> Do you mean so that the same peripheral is aliased in multiple
> locations? Or are you talking about multiple instances? Separate
> instances (e.g. UART0, UART1, UART2...) would of course have different
> base addresses.
I meant the latter. Now that I think about it it is obvious that it is
supported :-}
Felix
> >
> > 4.1.4: I don't understand "2^32 + 1 == 0x1 0000 0000".
> > Should it not be "2^32 == 0x1 0000 0000"?
>
> Wow, what a brain fart! What I was trying to reiterate was that the
> total number of units in an address space was the top address
> + 1, e.g.
> 0xFFFFFFFF + 1. Not sure how I thought that was 2^32. On a related
> topic (brain-fart prevention), you all will be pleased to know that
> SPIRIT allows you to define unit counts with integers as well
> as strings
> like "4K", "64M", "4G", "128k" etc. Which greatly reduces
> the chance of
> people screwing it up. ("lets see, I have 128k of RAM, so what is the
> unit count in hex? 0x1ffff?" OOPS! Mysterious "debugger bugs"
> that take
> hours to track down!)
>
> > Thanks,
> > Felix
> >
> > > -----Original Message-----
> > > From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > > Sent: Wednesday, March 01, 2006 7:32 AM
> > > To: dsdp-tm-dev@xxxxxxxxxxx; dsdp-dd-dev@xxxxxxxxxxx
> > > Subject: [dsdp-tm-dev] Target/Board description requirements:
> > > your thoughtsrequested
> > >
> > > Hello everyone,
> > >
> > > After the Toronto meeting I went ahead and took my
> > presentation, along
> > > with notes that I took from everyone while we were
> > brainstorming, and
> > > cobbled together a first pass requirements document
> > regarding target
> > > information needed for debugging purposes. Doug has posted
> > it in the
> > > downloads section of the Wiki site at:
> > > http://wiki.eclipse.org/index.php/DSDP/DD/Spirit.
> > >
> > > Note that the purpose of this document is purely requirements
> > > gathering at this point. I suppose the idea that it will
> > be XML might
> > > be implied, but I tried to steer away from explicitly saying how
> > > anything should be done.
> > >
> > > The document in its current form has a first cut at
> > information about
> > > memory maps and registers, and a bit of information about cores
> > > (nowhere near complete). It is also missing scan chain
> > information,
> > > so that would be great if folks could speak to that.
> > >
> > > Here is my plan for moving forward:
> > > 1) solicit feedback from everyone in this community regarding the
> > > requirements themselves
> > > 2) add these additional requirements to the document
> > > 3) goto 1 as until we stabilize...
> > > 4) Approach SPIRIT with these requirements to see where
> we go from
> > > here...
> > >
> > > My colleague John Wilson, who has been Mentor Graphics
> > representative
> > > on the SPIRIT steering committee, tells me that they are having a
> > > SPIRIT roadmap meeting the first week of March to decide
> on future
> > > directions for SPIRIT. He also said that ARM has
> > apparently already
> > > pushed for debugger topics to be a part of the agenda,
> > which is great.
> > > (Anthony, was that you that introduced that?) Yes, today
> is March
> > > 1st, so we might have missed the opportunity to actually submit
> > > something for the meeting, but this document might help the
> > > discussion.
> > >
> > > I think it would be great if we could have a tangible set of
> > > requirements finished, and from that create a document to
> > present to
> > > the SPIRIT community the set of information that we see
> as missing
> > > from the SPIRIT spec to make it truly useful for debugging.
> > >
> > > the floor is open!
> > > Aaron
> > >
> > > --
> > > Aaron Spear
> > > Debug Tools Architect/Staff Engineer
> > > Accelerated Technology a Mentor Graphics Division
> > > _______________________________________________
> > > dsdp-tm-dev mailing list
> > > dsdp-tm-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-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
>
