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

Shabtay,

On the C side, only supporting blocking interfaces will not allow
implementation of non-blocking operations which TLM models
require.

One can argue that on the HDL side we can keep things blocking.
But I think sooner than later we should design the interface
to have symetric capability on both sides in anticipation
of HDL-side TLM models.

As long as it can be done deterministically I see no reason
not to support it.

Hopefully I can clarify more in my proposal.

-- johnS


Shabtay Matalon wrote:
> 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
> 
> 
> 
>   
> 
> 
>