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

Hi John,

>
>johnS:
>It can. But I think this makes it more complicated
>that way.
>
>Here's my reasoning:
>
>Why implement a
>
>    library on top of a
>        library on top of
>             DPI
>
>when you can define it as two simpler problems kept
>independent:
>
>library1 on top of DPI
>
>library2 on top of DPI
>
>I think this contains the scope of the problem much
>more nicely. It also lets a lot of common decisions
>made for one library apply for the second since where
>there are similarities.
[Shabtay] John, I think this now throws the problem at the user to
understand each interface and figure out what to use. 

>johnS:
>Right now the TLM-API is only defined in an OSCI SystemC
>context based on classes and communication is only defined
>between SystemC and SystemC - not between SystemC and HDL.
>
>So, by creating an ANSI C DPI function interface that
>follows TLM semantics, we can easily build TLM compliant
>bridges or adapters between OSCI-SystemC TLM modules and
>synthesizeable, acceleratable HDL.
[Shabtay] You are correct about TLM being a SystemC protocol.  So the
adaptor will need to be implemented in SystemC as a bridge between
SystemC TLM and the C API we defined on the SW side. Assuming DPI subset
and pipes present the C API, I don't understand why the TLM library
should not be written as SystemC adaptor/s that encapsulates the pipes
and DPI on the SW side. If pipes are not capable of being the underlying
transport layer, we should revisit the pipes semantics rather than
creating a different implementation for pipes that is TLM compatible.

Can you mention which incompatibilities you identified in the pipes to
allow pipes to be encapsulated within SystemC TLM adaptors? What
prevents us from addressing these incompatibilities besides being rushed
to complete SCE-MI 2.0?