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

From: John Stickley <john_stickley_at_.....>
Date: Tue Jan 31 2006 - 08:27:25 PST
Per,

Good questions.

Commends embedded:

Per Bojsen wrote:
> Hi John,
> 
> 
>>As defined now the pipes are not TLM compliant.
> 
> 
> Could you explain in detail why they are not compliant?  Is
> it just that they do not follow the TLM style or is it more
> fundamental than that, e.g., that it is impossible to write
> a gasket layer that interfaces pipes to TLM?  I'd like to
> understand this better before adding more to SCE-MI 2.

johnS:
The main reason is that pipes - by definition only
support a blocking interface. And this was intentional
to ease the creation of optimized, emulator centric
implementations and retain determinism.

Also to more closely match semantics of Unix streams
and their ease of use. So I don't think we want
to change this basic simple to understand, simple to
use usage model.

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.

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.

So I think it is easier to define two separate, simpler
interfaces and clearly define the semantics of each.

There are similarities in the two but the semantics
are different enough to keep them separate.

At least this is how I see it. I'm open to ideas
however.

> 
> 
>>I can have a proposal ready to put on the table next
>>week for the face-to-face if others are agreeable.
> 
> 
> I don't mind, but please make sure to add a detailed analysis
> as to why TLM support must be integral to SCE-MI 2.  That is,
> you must convince me that TLM support could not be implemented
> as an application layer add-on to SCE-MI 2.

johnS:
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.

 > Would it be possible
> to consider TLM support a sub-standard of SCE-MI 2, sort of like
> a library?

johnS:
Yes. In fact that's how I view pipes as well - a library over
DPI. The TLM fifos would be very similar.

> 
> Also, if you could outline why TLM support suddenly has become
> such a hot issue for you.

johnS:
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.

The good news is that TLM and DPI are already very well defined
in other standards so we really just need to "steal" the work
that has been done rather than having to invent the semantics
from scratch.

-- johnS
<eom>

> 
> Thanks,
> Per
> 
Received on Tue Jan 31 08:27:31 2006

This archive was generated by hypermail 2.1.8 : Tue Jan 31 2006 - 08:27:54 PST