RE: specifying definition for tlm2 compliance in LRM..

John-

I'm pretty certain that people who are using the term "TLM2 compliant" today are not
intending it to mean what you say directly below, and in fact would probably disagree with
your requirements below.

So, I think the responsible thing to do is to explicitly say that "TLM2 compliant" is meaningless and
a more precise term should be used.

-Stuart

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Monday, March 15, 2010 2:41 AM
To: Stuart Swan
Cc: owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
Subject: RE: specifying definition for tlm2 compliance in LRM..

Stuart, All,

Some musings on compliance ....

General point: do we still want to talk about TLM-2-compliance, or is it all 1666-compliance? I guess TLM-2-compliance is still a useful concept for IP distribution.

I think the term TLM-2-compliant could still be meaningful. Just follow this decision tree:

If talking about an implementation
then a TLM-2-compliant implementation shall implement everything in the LRM, including the utilities, and not just the interoperability layer

If talking about a model
then the set of all "hops" is partitioned into two mutually exclusive and exhaustive categories: base protocol or user-defined protocol
for the base protocol, TLM-2-compliant means obeying all the rules of the BP
for a user-defined protocol, TLM-2-compliant means using tlm_initiator/target_socket (or sockets derived from these)

Mind you, in the case of a user-defined protocol this definition of TLM-2-compliance is pretty weak. So, on reflection, perhaps Stuart is right and we should insist on any claim of TLM-2 compliance being qualified as Stuart suggests below.

John A

From:

Stuart Swan <stuart@cadence.com>

To:

"john.aynsley@doulos.com" <john.aynsley@doulos.com>

Cc:

"owner-systemc-p1666-technical@eda.org" <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>

Date:

12/03/2010 18:48

Subject:

RE: specifying definition for tlm2 compliance in LRM..

________________________________

John-

Looks good. Reading your description below I infer the following terms
that need to be explicitly defined in the LRM:

"TLM2 base protocol compliant"
"TLM2 custom protocol compliant"
"TLM2 compliant implementation"
"TLM2 compliant" -> Meaningless term. Instead, pick one of the terms above. We should state this explicitly in LRM.

Comments?
Additions?

Thanks
-Stuart

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, March 12, 2010 6:38 AM
To: Stuart Swan
Cc: owner-systemc-p1666-technical@eda.org; systemc-p1666-technical@eda.org
Subject: Re: specifying definition for tlm2 compliance in LRM..

Stuart,

I agree. Personally I've been telling a fairly consistent story about TLM-2.0 compliance for a while now - see the DVCon 2010 TLM-2.0 tutorial. I would be pleased to debate this in the WG then clarify the text of the LRM accordingly.

In essence...

The entire (TLM-2.0) LRM is normative
but the status of the various sections does vary

The interoperability layer consists of
- Core interfaces
- Global quantum
- Standard sockets
- Generic payload
- Base protocol

Outside the interoperability layer we have
- Utilities
- Coding styles
- TLM-1

The user has two choices (to create a TLM-2.0-compliant model):
1. Use tlm_base_protocol_types and obey ALL the rules of the interoperability layer
or
2. Create a new protocol traits class, and change the rules

In case 2, the interoperability layer and base protocol play the role of a set of guidelines rather than a set of obligations. In other words, users are recommended to stick as closely as possible to the base protocol, but are allowed change the rules arbitrarily where necessary.

The utilities are normative not in the sense that users are required to use them but in the sense that implementations are required to implement them. Every TLM-2.0 implementation is obliged to provide a set of utilities with the API given in the LRM.

At least, that's my story.

John A

From:

Stuart Swan <stuart@cadence.com>

To:

"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>

Date:

11/03/2010 19:14

Subject:

specifying definition for tlm2 compliance in LRM..

Sent by:

owner-systemc-p1666-technical@eda.org

________________________________

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.