Re: TLM extensions - GP flags and extensions

Jerome,

I'm fine with John's last proposal in combination with Bart's comments,
to add a specific attribute for this purpose. This should not too
deeply interfere with "real" versioned payloads in the future.

Greetings from Oldenburg,
  Philipp

On 10/12/10 10:52, Jerome CORNET wrote:
> Philipp,
>
> I understand your point of view. But we have to be somewhat
> pragmatic.
>
> If we do nothing now, there is little chance that something will
> ever evolve. This seems a bit strong and pessimistic, but remember that
> we will probably have binary compatibility constraints with future
> OSCI TLM-2 evolutions. Next time we will be again in a position of doing
> such a modification (adding an attribute to the payload) will be 2015/2016.
> That is a bit far...
>
> In the contrary, if we do something like adding the attribute as per
> current proposal, we can use it as a foundation for future versioning.
> You will agree that clearly, versioning is not simple as incrementing
> a version value in the payload, because of all the discussions on payload
> reinitialization in pooling (you know my opinion about that, and I am not
> alone, but I think it is more constructive to find a solution that will
> suit the maximum number of participants).
>
> So, I think that what we can do to take into account your remark in the
> current proposal is to think minimally about how to design the attribute
> in such a way that it could be used by a future IEEE/TLM2 WG committee to
> make an evolution if it is necessary, and that it is not possible/reasonable
> through other means.
> That means, we should refrain from doing something ad-hoc. To me, this is
> achievable by very small details: maybe the naming of the enum attribute,
> the size of the attribute (maybe use something like a bit field? with additional
> bits that could be defined?). We don't necessarily needs to have already a full
> idea of future versioning proposal in mind.
>
> If we do nothing now, you can already forget about payload versioning...
>
> Jerome
>
>
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
> Sent: Thursday, December 09, 2010 7:35 PM
> To: john.aynsley@doulos.com
> Cc: Bart.Vanthournout@synopsys.com; eric.e.roesler@intel.com; Jerome CORNET; P1666 Technical WG
> Subject: Re: TLM extensions - GP flags and extensions
>
> 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
>
>

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