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.