RE: [dsdp-dd-dev] RE: [dsdp-tm-dev] Target/Board descriptionrequirements

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

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

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

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

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