RE: specifying definition for tlm2 compliance in LRM..

Hiroshi-

Comment below..

-Stuart

>-----Original Message-----
>From: Hiroshi Imai [mailto:hiroshi3.imai@toshiba.co.jp]
>Sent: Tuesday, March 30, 2010 3:20 AM
>To: Stuart Swan
>Cc: systemc-p1666-technical@eda.org
>Subject: Re: specifying definition for tlm2 compliance in LRM..
>
>Stuart,
>
>Thanks for your explanation of "TLM2 compliant implementation". Its
>meaning becomes clear to me. Thanks.
>
>About API:
>By using sockets and traits classes I can check the "base protocol
>compliant" or "custom protocol compliant" at the compile time through
>compile errors. Is my understanding correct?
>

Yes, that is their intent and that is exactly what they do.

>About definition of compliant:
>I agree with your main point. These definitions make clear the
>difference between base-protocol-model and custom-protocol-model. Then,
>they make it clear how much interoperable a model is.
>
>Best regards,
>Hiroshi Imai
>Chair of SystemC WG, JEITA
>
>At 29 Mar 2010 11:26:27 -0700 Stuart Swan wrote:
>> Hiroshi-
>>
>> "TLM2 compliant implementation" refers to the SystemC environment
>> that provides the required TLM2 services for various TLM2 models.
>>
>> I don't think the API you propose is needed for determining base protocol
>> and custom protocol models since the sockets and traits classes already
>> provide this ability. The main point I was making is that the LRM needs
>> to clearly define these terms, since there seems to be confusion in people's
>> minds.
>>
>> Thanks
>> Stuart
>>
>> >-----Original Message-----
>> >From: Hiroshi Imai [mailto:hiroshi3.imai@toshiba.co.jp]
>> >Sent: Monday, March 29, 2010 2:48 AM
>> >To: systemc-p1666-technical@eda.org; Stuart Swan
>> >Subject: Re: specifying definition for tlm2 compliance in LRM..
>> >
>> >Stuart, All,
>> >
>> >From the point of view of model users, it is very important to define
>> >"TLM2 base protocol" and "TLM2 custom protocol compliant". When we use
>> >third vendor TLM models, our concern is whether we can connect them to
>> >our own models and whether they can communicates. These definitions can
>> >get rid of such concern.
>> >
>> >So, the definitions of "TLM2 base protocol" and "TLM2 custom protocol
>> >compliant" should be included in the LRM.
>> >
>> >To check how compliant a model is, it is useful to define an API, like
>> >sc_version(), which returns a value "TLM2 base protocol compliant" or
>> >"TLM2 custom protocol compliant".
>> >
>> >About "TLM2 compliant implementation", it seems ambiguous. We'd like to
>> >make clear its meaning and understand the objective to define it.
>> >Is "implementation" related to model implementation or SystemC
>> >environment to provide TLM2?
>> >
>> >Best regards,
>> >Hiroshi Imai
>> >Chair of SystemC WG, JEITA
>> >
>> >At 11 Mar 2010 11:13:51 -0800 Stuart Swan wrote:
>> >> John, All-
>> >>
>> >> I'd like to propose that we provide some precise definitions
>> >> for terms like "TLM2 compliant" models and implementations within
>> >> the IEEE LRM.
>> >>
>> >> My concern is that there may be model and tool builders out there
>> >> who think that they can pick and choose which parts, and which rules,
>> >> of the LRM that they want to implement/adhere to, and which ones they wish to
>> >> ignore, and then go on to claim TLM2 compliance.
>> >>
>> >> As an example, the OSCI LRM has very clear rules about obligations on
>> >> models if non-ignorable extensions are in use, but it is very easy for
>> >> model developers and users to simply ignore these rules.
>> >>
>> >> I think we basically need to inform casual readers that they cannot
>> >> simply choose to ignore rules in the LRM if they don't feel they suit their needs.
>> >>
>> >> I realize that we may need to define a number of terms .e.g "compliant
>> >> with TLM2 base protocol and generic payload", etc., but I think it is worth
>> >> the effort.
>> >>
>> >> Comments?
>> >>
>> >> Thanks
>> >> Stuart
>> >>
>> >> --------------------------------------------------
>> >> Stuart Swan
>> >> Senior Solutions Architect
>> >> Cadence Verification Division
>> >> stuart@cadence.com
>> >> --------------------------------------------------
>> >>
>> >>
>> >>
>> >> --
>> >> This message has been scanned for viruses and
>> >> dangerous content by MailScanner, and is
>> >> believed to be clean.
>> >>
>> >>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.