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.