Re: John's SCE-MI 2/TLM Ideas (was Re: Message from John)

Per,

Quick comments to add to all your points (which I agree with
by the way) ...

Per Bojsen wrote:
> Hi Shabtay,
> 
> 
>>[Shabtay] I don't see the TLM API linked in any way to capabilities like
>>streaming, data shaping or variable length message.
> 
> 
> Why not?  It deals with transporting arbitrary objects of
> arbitrary size, so VLM and data shaping seems quite relevant
> for the transport layer over which a TLM interface is built
> if that layer is channelized and not shared memory.
> 
> 
>>I have already checked this with a TLM expert at Cadence and found out
>>that TLM does NOT require that we support all interface types. So from
>>TLM compliance stand point, we could suffice supporting only
>>non-blocking unidirectional interface and yet be TLM compliant (We still
>>need to look at this however from all other perspectives).
> 
> 
> Well, I don't think the idea is for us to support TLM just so
> we can put a checkmark next to the TLM support bullet.  If we
> decide to embrace John's TLM support API proposal we should
> consider what makes sense and not what is the minimum required
> just so we can say we support TLM.
> 
> 
>>I don't see how TLM compliance alleviate or is related to the issues of
>>streaming, data shaping and variable length message
> 
> 
> TLM compliance does not alleviate any of those issues.  It is
> the other way around: providing a solution for data shaping
> and VLM gives implementations avenues for optimizing the transport
> layer on top of which TLM interfaces can be built.
> 
> 
>>I also don't see much room for transport layer optimizations if the
>>scope of TLM is kept to interface definition and argument passing.
> 
> 
> Again, we are not dealing with TLM directly, but rather with a
> C API that will allow TLM compliant interfaces/adaptors to be
> built on top of SCE-MI 2.
> 
> 
>>As
>>TLM API is syntactically compliant with SystemC, what I think we should
>>aim for is that the transport layer (for example pipes) will be
>>syntactically close to TLM API and semantically compatible.
> 
> 
> Since TLM is C++ template class library and John's TLM support API
> is a C API I don't know what `syntactically close' means.  About
> all we can do is to choose similar names for C API functions that
> are similar to the C++ template methods defined by TLM.

johnS:
The goal is not to be syntactically compliant. Just
semantically compatible. i.e.you need the equivalent of
the basic operations so you can easily build syntactically
compatible SystemC wrappers over SCE-MI 2.

> 
> 
>>and will allow full reuse of the
>>pipes code and won't require additional optimizations.
> 
> 
> I don't know how you leap from `syntactically close' and
> `semanticall compatible' to `allow full reuse of the pipes
> code'.  And I don't understand what you're saying about
> not requiring additional optimizations.  In specing the
> SCE-MI 2 APIs and interfaces we are not requiring any
> optimizations.  Optimizations are up to the implementations.
> In regards to VLM, data shaping, and streaming, one of the
> main reasons to incorporate these in the standard was to
> provide opportunities for the implementations to optimize
> the transport of large messages.  But this does not imply
> that any given implementation is required to do such
> optimizations.  They may not even be relevant.
> 
> 
>>I am definitively not in favor of building and attempting to optimize
>>two versions of pipes both from implementation perspective and end user
>>perspective.
> 
> 
> I'd also like to explore either enhancing the current pipes
> proposal or replace it with the new TLM support API proposal
> if it is possible to achieve the VLM, streaming, and data
> shaping features of the current pipes proposal with a new
> consolidated TLM support/pipes API.

johnS:
Again, I see both you and Shabtay wanting to move in this
direction. Perhaps I'll realign the proposal in this direction.
So far we've done them separately but the idea of combining
them is growing on me.

Ironically the "hook" interface I proposed last week also
provides an avenue to do this.

-- johnS
<eom>

> 
> 
>>The only differences that
>>could be justified are minor syntax differences that stem from the fact
>>the TLM API only runs in SystemC.
> 
> uy7
> Well, as John pointed out, it is possible that combining the
> two APIs lead to an overly complex API (from implementation and/or
> usage points of view) such that we are better off providing two
> separate APIs.  But we have to see the TLM support API proposal
> to find out.  Another reason for not abandoning the pipes would
> be if they provide some significant features that are incompatible
> with the TLM support API.
> 
> Per
>