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.