Re: TLM extensions - GP flags and extensions

Philipp, Bart, Jerome, All,

The more I think about it, the more I think changing the core interfaces is a non-starter. Any change would potentially have to be implemented by all custom protocols too.

As Bart says, we could have a flag and oblige the initiator to clear it. For GP transactions using a memory manager, we can make this foolproof by clearing the flag in tlm_generic_payload::reset(), effectively getting the same advantages as using auto_extensions. For non-memory-managed transactions, the initiator would have to be responsible for clearing the flag.

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

These could then be implemented under-the-hood by two auto-extensions to static extension objects (for efficiency). But the downside is that auto-extensions require the presence of a memory-manager, which rules out this solution.

John A

 

-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: Jerome CORNET <jerome.cornet@st.com>
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 12/09/2010 12:44PM
Cc: "Roesler, Eric E" <eric.e.roesler@intel.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>, Bart Vanthournout <Bart.Vanthournout@synopsys.com>
Subject: Re: TLM extensions - proposal

Jerome,

although I tried to extend Eric's proposal to improve it towards more
backwards compatibility, I accept John's disapproval to changing core
_interfaces_ for _protocol_ evolution. This may indeed not be the right
way to pursue.

  OTOH, I strongly agree with you, that a "standard extension" should be
avoided as well. I would also be willing to sacrifice backwards
compatibility in this special area, but I'm more in the user camp and
not a vendor of a large pool of "legacy" models. So Bart obviously has
a point here as well.

IMHO, the remaining options are:

 1) Exclude it from this round of standardisation and discuss
    it in the TLMWG (Tor's vote, I tend to agree).

 2) Add a "protocol version/indication" to the GP and specify the rules
    for it in a way that old initiators are working correctly.

  Of course, we can require new initiators to always reset the version
field at the end. But this looks error-prone and fragile and might lead
to hard to track bugs at seemingly unrelated places if forgotten.
Moreover, this would be the first field that has to be reset after a
transaction has finished.

  If we can somehow automate the reset of this attribute (e.g. within
release(), if ref_count == 0), we might reduce this risk. (In an ad-hoc
managed context, the GP object is probably not used across old and new
initiators).

  Wrt. DMI response_status: Are there any open compatibility issues? I
thought, this has been resolved since the initiator obviously has to
reset the response_status if it wants to see any changes by the target
to it and that the target is not obliged, but encouraged to set the
response_status to indicate a more detailed error.

My 1.5 ¢,
  Philipp

On 09/12/10 12:58, Jerome CORNET wrote:
> Eric, Philipp,
>
> thanks for your proposal, which really tries to address the problem.
> Personally, I am ready to vote for any proposal that actually address the problem,
> that gain the agreement of the "extreme backward compatibility" camp without
> delaying to unspecified times the actual evolution of the standard.
>
> However, I note that the versioning proposal was in good shape to win the heart of
> the extreme backward compatibility camp (although Philipp has some technical objections we
> have to discuss), and in addition, remember that we have also to address the response
> status of DMI. With your proposed technique, we would also have to modify the DMI
> interface. That sounds more complicated that the "versioning" proposal?
>
> Maybe we should focus of solving the remaining problems with the most promising additions?
> What do you think?
>
> Thanks,
>
> Jerome
>
>
> -----Original Message-----
> From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Roesler, Eric E
> Sent: Thursday, December 09, 2010 2:25 AM
> To: Philipp A. Hartmann
> Cc: john.aynsley@doulos.com; P1666 Technical WG
> Subject: RE: TLM extensions - proposal
>
> Right, I see that my #2 would require the method prototypes to be updated in all the existing models.
>
> I like the enum in place of the bool, allowing more flexibility.
>
> As far as the pure virtual, couldn't the interface methods remain pure virtual, and handle the backward compatibility in the socket implementation of the methods? I confess I'm not as familiar with the internal implementations of the sockets.
>
>
> EricR
>
>
>
>> -----Original Message-----
>> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>> Sent: Wednesday, December 08, 2010 3:34 PM
>> To: Roesler, Eric E
>> Cc: john.aynsley@doulos.com; P1666 Technical WG
>> Subject: Re: TLM extensions - proposal
>>
>> Eric, John, all,
>>
>> sorry for the lengthy mail.
>>
>> Personally, I'd prefer the extended interface as well.
>> Unfortunately,
>> with both of Eric's proposals only backwards compatibility wrt. the
>> initiators can be achieved. _All_ targets would require changes to
>> actually implement the new interface instead, which may be trivial but
>> is probably not acceptable.
>>
>> I tried to find a working solution for this, since I don't like to
>> standardize extensions as well.
>>
>> AFAICS, the only solution that _might_ work, is the something like
>> following one. It's not really clean, but at least enables an
>> incremental migration towards the new interface/protocol.
>>
>> enum tlm_dbg_version {
>> TLM_DBG_SIMPLE,
>> TLM_DBG_STRICT
>> };
>>
>> template <typename TRANS = tlm_generic_payload>
>> struct tlm_transport_dbg_if
>> : public virtual sc_core::sc_interface
>> {
>> // backwards compatibility
>> virtual unsigned int transport_dbg( TRANS& trans );
>>
>> // new function
>> virtual unsigned int transport_dbg( TRANS& trans, tlm_dbg_version );
>> };
>>
>> Note, that both functions are NOT pure virtual. This is sad but on
>> purpose to enable the migration path. The rules are roughly the
>> following:
>>
>> 1) Targets shall override exactly one of the two functions.
>> New targets should choose the new interface, the old interface
>> is deprecated.
>>
>> 2) Recommend, that initiators should use the new function.
>>
>> 3) For the old function, the base implementation shall call the new
>> function with TLM_DBG_SIMPLE, to support legacy initiators using
>> the old interface on new targets only implementing the new
>> interface.
>>
>> 4) For the new function, the base implementation shall call the old
>> function, iff
>> - the requested version is TLM_DBG_SIMPLE, or
>> - extended attributes are not set
>> It shall return the same return value and update the
>> response_status.
>>
>> If TLM_DBG_STRICT is requested with extended features, it shall
>> do nothing and the response_status shall be set to an error
>> response. In any case, a warning shall be generated?
>>
>> With this path, we can support all combinations of old and new targets
>> and initiators in an API compatible way. Since we need to translate
>> between both versions, we need basic implementations for both
>> functions.
>>
>> Of course, we need overloads to register both, new and old functions
>> in the convenience sockets as well. Potentially with a warning for the
>> "old" registration. At least with a check, that not both versions are
>> registered.
>>
>> Thoughts?
>>
>> 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://offis.de/en/ 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.