RE: TLM extensions - proposal

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
>

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