RE: TLM extensions - status

Philipp,

very good questions as always :-) See answers below.

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Wednesday, December 08, 2010 5:16 PM
To: john.aynsley@doulos.com
Cc: Stuart Swan; Bart Vanthournout; Jerome CORNET; stanleyk@cadence.com; P1666 Technical WG
Subject: Re: TLM extensions - status

>> John, all,

>> I also think, that the addition of versioning the BP might be a good
>> path for the future. But I'm a bit hesitant to embrace this in this
>> short time frame we have left now.

>> I fear the following issues:

>> 1) How can the addition of an additional field (which needs to be
>> properly initialised when reusing payload objects) solve the
>> backwards compatibility issue?

>> If we have a shared transaction pool for multiple initiators,
>> the newly added attribute may be wrong, if not explicitly set
>> by an "old" initiator. Which does not know anything about it.
>> So it's even worse, since not just the "poorly coded" initiators
>> are affected.

I don't think this is much a problem, as the only issue is *reinitialization*
of values in the payload.
In we were to adopt this solution, the constructor of the generic payload would
 be modified to initialize the additional attribute to a sane default value.

So an old initiator would send a default value, whereas a "new" initiator would
send the payload with a value indicating that it understands the new rules.
The only requirement is that a new target does change the generic payload only if
it does detect a new initiator. In other cases, the generic payload will have
correct default value for the attribute, this value will not be altered subsequently
either by the target or the initiator when reusing it.

Does it answer your question?

>> 2) We break API compatibility with OSCI TLM 2.0 (not only binary
>> compatibility due to a new kit). This leads to preprocessor
>> clutter in many models, that intend to support both versions.

I understand your point. However, in general the IEEE 1666-2010 will
provide new APIs that you will be able to use only inside #if directive.

I you push for that point thought, maybe we could design the get_byte_enable_ptr()
and other related accessors in such a way that they manage automatically
the "versioning" attribute. But that would be probably complex to design,
and I think this is preferable we agree on a solution first.

You also implicitly raise the binary compatibility point, which I think we
need to talk a little bit about.

I think that IEEE 1666-2010 implementations are not mandated to guarantee
binary compatibility with IEEE 1666-2005 binaries. Probably they can't even
do that in practice, given the changes required within the various classes
used directly in the models.

Therefore, people will anyway need to recompile their models if they want
to use them in an IEEE 1666-2010 context. Therefore.... this is a good
time to make changes to the generic payload that we wouldn't be able to do
in a regular TLM-only OSCI release. This another reason why I think adding
another attribute to manage base protocols possible evolutions is not that
bad.
Please however note that this would be intended for base protocol evolutions only,
not to standardize things that are orthogonal and for which it would make
perfect sense to do extensions (such as standardizing locking or so on, as
John demonstrates in his tutorials if I remember well).

>> 3) Do we actually catch all other caveats with the proposed
>> versioning, if we define it in a quick shot now?

I think so.

However, I definitely agree with you and Mac that we are discussing changes
that would not be required if we were to consider honestly the residual backward
compatibility issues of my original proposal. But, I am not against finding a
more complex solution that would suit everyone.

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