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

Hi John,

 

I agree that we should look at the TLM compliance issue and I would be
interested to see your proposal before making more specific comments. I
think your email raises some important questions including:

 

a)       Should we consider the TLM standard when reviewing pipes? I
think that my answer to that is yes for the reasons you indicated in
your email.

 

b)       Should the pipes be modified to be TLM compliant or should we
use a separate TLM library that implements equivalent functionality?
Intuitively I'd rather align the pipes interface around TLM or at least
define it to comply with key TLM requirements. I would thus be
interested not only in your TLM proposal but also in your analysis and
the tradeoff you see going separate or combining the two. On this issue,
if we end up creating 2 separate libraries as you seem to lean to, which
library should be used with SystemC testbench; the pipes version or the
TLM version? TLM is only defined for SystemC while pipes could be used
in the context of any HVL and C/C++ with any non-preemptive threads. Are
we going to promote one interface for SystemC and another for non-system
environments?

 

c)       Does the use of TLM mandate that the API offer a non-blocking
option? You indicated that "with TLM you also need non-blocking support
(in addition to blocking) on both ends of the channels". I am not sure
if TLM requires it or just supports it. For example TLM supports also
bi-directional blocking interface which we probably will not support. I
would suggest that we address the non-blocking vs. blocking wrt to our
threading discussion and capabilities required by the interface. Even in
DPI we have taken the liberty of using a subset of the spec for
acceleration. I thus don't see a reason that the TLM standard will
impose on us presenting all its interfaces. I can check on that with
some TLM experts and maybe you check if your comment was correct on your
end.

 

d)       Your email indicates that you view pipes and TLMs as libraries
on top of DPI. I think we'll need to determine what our position is
about these libraries wrt SCE-MI 2.0 scope. If the DPI subset represents
a common transport layer that can be used directly by users/modelers and
also used as a transport layer by the library, than each vendor or user
can build their own library, provide it as part of the tool or
verification model and interoperability is guaranteed among all models
given that each is basically using the common SCE-MI 2.0 DPI subset. But
if these pipes/TLM libraries are defined in the SCE-MI 2.0 spec with a
requirements for verification components to comply with these
interfaces, we need to solidify the interface definition to the same
level of the DPI subset spec and make sure that we don't come up
tomorrow with another idea that modifies the SCE-MI 2.0 interface again.
I think that this issue will requires some significant consideration
given where we are the SCE-MI 2.0 definition process schedule wise.
Rushing this up or assuming that we can resolve the current issues in
few weeks or months may not be the right way to go.

 

Shabtay

 

  

 

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John

>Stickley

>Sent: Tuesday, January 31, 2006 8:27 AM

>To: bojsen@zaiqtech.com

>Cc: itc@eda.org

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

> 

>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

>>