RE: TLM API and SCE-MI

John,

Thanks for your clarifications. I have renamed this email thread for
future use.

See my notes inserted, but in a nut shell, I think we need to move the
discussion from what an interface can do to how it addresses the need
for creating portable transactors. 

I assume that Matt will address your responses directed to him. 

Shabtay

>
>Shabtay Matalon wrote:
>> Based on my experience, there is also a need for proxy model in
between
>> a TLM and SCE-MI API or between a TLM and the HVL encapsulation
layer.
>> As a minimum, it needs to configure the BFM on the HW side. Are you
>> stating that a generic layer can be a replacement for a proxy model
of
>> just an add-on?
>
>johnS:
>The beauty of the TLM-API approach is that it essentially allows
>removal of the proxy altogether and replacement of it with a TLM
>channel directly from the TB to the HDL transactor, through its
>sophisticated use of parametrized transaction types. This was
>somewhat illustrated in one of the slides accompanying our proposal
>(see "possible implementation layers-emulator platform" slide).
>In this case the "proxy" is more or less reusable C++ template code
>that implements a channel, not companion model the user must create a
>distinct version of to accompany each HDL transactor type.
[Shabtay] From a pure technical perspective, this could be done. From a
transactor portability perspective, I would not recommend it as the BFM
requires a proxy model either because some of the bus protocol is
embedded in the proxy model, or given that it might be easier on the
modeler to model some of the functionality on the SW side, or given that
the transactor may be connected to TLM that doesn't know how to
configure it or given that the proxy contains randomization that could
be easily modeled in SW. In the general case, I would assume that
transactors will have a BFM and a proxy model. The proxy model could be
very thin in some cases and heavy duty in others (see my notes about
minimal definition of transactor architecture).

I hope this clarifies my statement above.

>
>Shabtay Matalon wrote:
>> We are not promoting use of controlled clock either in our proposal,
but
>> can you explain what is the difficulty of creating blocking and non
>> blocking interfaces for the existing SCE-MI SW API? We have easily
>> implemented such an interface for SystemC based on the existing
SCE-MI
>> callbacks.
>
>johnS:
>My earlier e-mail suggested that both blocking and non-blocking
interfaces
>can be supported on the S/W side of the API - basically fulfillment of
>interfaces such as the OSCI TLM-API standard interface method calls,
>tlm_put_if::put(), tlm_put_if::nb_put(), tlm_get_if::get(), and
>tlm_get_if::nb_get().
>
>My comment was that with pre-implemented DPI pipes, implementation of
>these methods tends to be easier than dealing directly with callbacks
>and surrounding application code that must deal explicitly with the
>threading layer.
>
>Bear in mind that DPI pipes as proposed can, as one possibility,
>be implemented as a simple C code library over a base compliant DPI
>facility.
>
>This C-code library is where thread interfacing code tailored to a
>specific threading environment can be encapsulated. But this can be
>a one-time reusable implementation that can be provided by the
implementor
>rather than something that has to be done separately for each
application
>proxy model that is implemented using callbacks.
[Shabtay] OK. What you have described then is what I called an HVL
encapsulation layer. In the broader sense, HVL could be a C-Code with a
given threading package. If you don't like this name, we can call it
TLM2C adaptor or simply HVL2C adaptor as some for of the OSCI TLM-API
can be extended over time to multiple languages (such as SystemVerilog
and e).

HVL2C adaptors can be easily created and provided to end users on top of
the existing SCE-MI SW side API. Thus 

a) The user shouldn't care if it is difficult or not
b) Actually we found it to be quite an easy exercise for the OSCI
TLM-API standard.

However, please clarify your statement about DPI pipes and TLM - API.
Your proposal states that transaction pipes are only needed for
"variable length messages and steaming extensions".

Are you now saying that the HVL2C is dependent on calling the send and
receive functions in the pipes library that EDA vendors will provide? If
"the function call is transaction", why is this layer dependent on the
transaction pipes? Please let me know if it does or it doesn't and if it
does, what makes it depended on pipes.