RE: TLM extensions - proposal

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

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