RE: TLM extensions - GP flags and extensions

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.