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

Per,

>I believe the reason for making pipes and possibly the TLM support API
>part of the SCE-MI 2 standard is at least twofold:
>
>  1) Ensure all compliant SCE-MI 2 implementations provide these APIs
>     which provide variable length messaging and streaming.
>
>  2) Provide avenues for the implementors to provide transport layer
>     optimizations in support of VLM and streaming.
>
>Application layer solutions would not be able to get the benefits
>of (2).
>
>Per
[Shabtay] I don't see the TLM API linked in any way to capabilities like
streaming, data shaping or variable length message. It primarily defines
a blocking and non-blocking semantics (which is critical to SystemC as
you cannot block if you call the interface from SC_METHOD) and defines
how arguments are passed. It also defines a bi-directional interface
which to my judgment is irrelevant to SCE-MI.

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

I don't see how TLM compliance alleviate or is related to the issues of
streaming, data shaping and variable length message, but I'd be
interested to find out if one could demonstrate how it does. I think a
good starting point is to review John's TLM proposal first. I don't know
which of the TLM interface classes John plans to propose.

I also don't see much room for transport layer optimizations if the
scope of TLM is kept to interface definition and argument passing. 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. This will
make the SystemC adaptor very lean and will allow full reuse of the
pipes code and won't require additional optimizations.

I am definitively not in favor of building and attempting to optimize
two versions of pipes both from implementation perspective and end user
perspective. The issue from the end user stand point is not just
guidelines and examples but rather providing a uniform approach to
calling and argument passing to the interface. The only differences that
could be justified are minor syntax differences that stem from the fact
the TLM API only runs in SystemC.

I am afraid that we can't avoid enhancing pipes to address this in
addition to few others issue that we haven't resolved yet. I am yet
wondering if this all should be done in the context of SCE-MI 2.0 or
not.

Shabtay



  
>