RE: TLM extensions - proposal

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.