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

On 08/12/10 22:23, Roesler, Eric E wrote:
> Sure, and I’d be OK with that too. Though it seemed there was
> resistance earlier in the thread to standardizing an extension.
>
>
>
> Also, there is a slight performance and productivity hit – checking for
> the extension, managing the extension memory allocation. For cases
> where extensions are already being used it would be trivial, but it to
> add it when not already using extensions would be a pain from a
> developer POV.
>
>
>
> EricR
>
>
>
>
>
> *From:*john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
> *Sent:* Wednesday, December 08, 2010 2:15 PM
> *To:* Roesler, Eric E
> *Cc:* Philipp A. Hartmann; john.aynsley@doulos.com; P1666 Technical WG
> *Subject:* RE: TLM extensions - proposal
>
>
>
> 1st reaction - could work, but would we do better to add a standard
> extension after all?
>
> John A
>
> -original message-
> Subject: RE: TLM extensions - proposal
> From: "Roesler, Eric E" <eric.e.roesler@intel.com>
> Date: 08/12/2010 10:15
>
> After thinking about the situation & re-reading the LRM 4.3 debug
> section, I have two ideas:
>
> 1. A new Debug API, same as existing but with "strict" tag
>
> template <typename TRANS = tlm_generic_payload>
> class tlm_transport_dbg_strict_if : public virtual sc_core::sc_interface
> {
> public:
> virtual unsigned int transport_dbg_strict(TRANS& trans) = 0;
> };
>
> Multiplex this in with the existing tlm_transport_dbg_if. Advantages of
> cleanly associating new method call with new rules (everything must be
> initialized). Disadvantage of adding cruft to socket inheritance tree.
>
>
> 2. Update the existing API, but add the ever-popular but ugly C++
> function parameter w/ default:
>
> template <typename TRANS = tlm_generic_payload>
> class tlm_transport_dbg_if : public virtual sc_core::sc_interface
> {
> public:
> virtual unsigned int transport_dbg(TRANS& trans, bool strict=false) = 0;
> };
>
> Advantage of avoiding some inheritance cruft, but some people hate
> default values for parameters.
>
>
> Fire away...
>
> EricR
>
>
> Eric Roesler
>
> Virtual Platform CoE
> Intel Corporation
> ph 480.554.7541
>
>
>
>
>
>> -----Original Message-----
>> From: Roesler, Eric E
>> Sent: Wednesday, December 08, 2010 10:41 AM
>> To: Philipp A. Hartmann; john.aynsley@doulos.com
>> Cc: P1666 Technical WG
>> Subject: RE: TLM extensions - status
>>
> . . .
>> This may not be what anyone wants to hear - but it seems the only way
>> to both maintain backward compatibility and have a standardized new
>> approach with tighter rules is to define a new enhanced debug API to
>> coexist with the original. Possibly deprecate the original at some
>> point.
>>
>>
>> Eric Roesler
>>
>> Virtual Platform CoE
>> Intel Corporation
>> ph 480.554.7541
>>
>>
>>
>
>

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