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

Per,

Per Bojsen wrote:
> Hi John,
> 
> 
>>But with TLM you also need non-blocking support (in
>>addition to blocking) on both ends of the channels.
>>And, you need "peek" ability in addition to basic
>>read/write ability.
> 
> 
> Ok, so TLM needs more from the interface than pipes can
> currently provide.  Just to clarify, since you are promoting
> both interfaces, I assume you have gone through the exercise
> of seeing if the pipes could be implemented on top of your
> new TLM interface as an application layer solution.  My
> question is simple: can it and if no, why not?

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.

   If the answer
> is no I'd like that to be part of your motivation for keeping
> the pipes next to the TLM interface.
> 
> 
>>I thought about adding this somehow to pipes but I think
>>it makes them even more complicated in terms of use model
>>and implementation model and it would complicate our
>>committee discussions even more - something we cannot
>>really afford at the rate we've been going.
> 
> 
> Well, the devils advocate could argue that adding another
> API to the proposal is in itself something that could complicate
> our discussions ;-)  Note, I am interested in learnign more
> about your proposal and exploring it.  I am just concerned
> that we make 100% sure we are adding something that will
> be complimentary to what we already have and useful as well.
> 
> 
>>Actually it can - and so can pipes for that matter. But, just
>>as for example the "iostreams" is an ANSI standard library of C++
>>so should pipes and TLM fifos be a standard library of SCE-MI 2.
>>This way, everyone implements and uses the library the same way.
> 
> 
> The TLM API is already defined.  So what you are proposing is
> a lower level SCE-MI 2 API on top of which TLM FIFOs can be
> implemented, correct?

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.

> 
> 
>>I won't say it is sudden. I'm just getting the feeling that
>>at the rate of progress in our discussions, SCE-MI 2
>>may be obsolete and inadequate by the time it is out because
>>transaction verification will be more aligned with the TLM
>>standard. I think it behooves us to make sure that SCE-MI 2
>>dovetails well with other emerging standards. By incorporating
>>it now, we extend the time window of its usefulness without
>>having to wait for SCE-MI 3 and thus lag the industry even
>>more.
> 
> 
> I agree with this as long as adding more features to `catch up'
> is not in the end going to slow us down even more.

johnS:
A fair enough concern. But here again, if we can get a concensus
on pipes we may have a good chance on getting a concensus
on the new library fairly quickly. Then again maybe not !

But if everyone on this committee really wants to see
it be successfull and all are willing to put in the effort
it takes to move it along I have to believe it's doable.

-- johnS
<eom>

> 
> Per
>