John,
wrt. to the additional functions in tlm_generic_payload, I think this a
might not be good idea for now. Consider future versions of the
standard, where we may want to add even more attributes or protocol
refinements that require similar mechanisms.
IMHO, we should define a robust, scalable way to evolve the BP inside
the TLMWG instead, e.g. built upon a versioning scheme. If we rush into
an ad-hoc interface now, we might need
recognize_even_more_extended_attributes() next time round… ;-)
It would be OK for me, if there's a decision towards the addition of a
specific attribute for the extended debug protocol with
byte-enables/streaming and solid rules around that. But as I said
earlier, I even prefer to define this properly on top of a future
versioned BP (response_status for DMI/Debug should be fine).
Greetings from Oldenburg,
Philipp
On 09/12/10 16:22, john.aynsley@doulos.com wrote:
>
> I was musing about an alternative: add some new methods to
> tlm_generic_payload:
>
> void tlm_generic_payload::set_extended_attributes(); // Called by initiator
> void tlm_generic_payload::recognize_extended_attributes(); // Called by
> target
> bool tlm_generic_payload::extended_attributes_recognized(); // Called
> by initiator
>
[snip]
-- Philipp A. Hartmann Hardware/Software Design Methodology Group OFFIS Institute for Information Technology R&D Division Transportation · FuE-Bereich Verkehr Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/ Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Dec 9 10:35:56 2010
This archive was generated by hypermail 2.1.8 : Thu Dec 09 2010 - 10:35:59 PST