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

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.

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

> The only differences that
> could be justified are minor syntax differences that stem from the fact
> the TLM API only runs in SystemC.

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

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488