RE: TLM-1 further remarks

Jerome, Stuart,

Re. 11.1 and 18.1.1, I agree with Jerome too. Here is a proposed
re-wording:

11.1 Background
...

b) TLM-1 has no explicit support for timing annotation, so no standardized
way of communicating timing information between models. TLM-2.0 addresses
this shortcoming with the addition of timing annotation function arguments
to the blocking and non-blocking transport interface.

c) The TLM-1 interfaces require all transaction objects and data to be
passed by value or const reference, which may slow down simulation in
certain use cases (though not all). TLM-2.0 passes transaction objects by
non-const reference, which is a fast solution for modeling memory-mapped
buses.

18.1.1 Description
...
TLM-1 imposes a further constraint ... In other words, if the transaction
object contains any pointers or references to shared memory outside of
itself, this standard does not specify the ownership, lifetime, access, or
update rules for such shared memory locations. Hence the responsibility
for the use of any such shared memory lies entirely with the application,
and should be carefully documented. Pointers or references to shared
memory should not be used as a backdoor communication mechanism.
...

I could live without the final sentence explicitly forbidding backdoor
communication (as proposed by Stuart) if it is too controversial.

John A

From:
Stuart Swan <stuart@cadence.com>
To:
Jerome CORNET <jerome.cornet@st.com>, "john.aynsley@doulos.com"
<john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
11/01/2011 19:39
Subject:
RE: TLM-1 further remarks

John, All-
 
I agree with Jerome?s points below.
 
Regarding the last point related to pointers in TLM-1 payloads, I think
the LRM should say that the standard does not specify ownership, lifetime,
and data modification rules in this case, and so it is recommended that
model writer clearly document the ?protocol? with respect to usage of the
pointer and that it not be used as a backdoor communication mechanism.
 
Thanks
Stuart
 
From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jerome CORNET
Sent: Tuesday, January 11, 2011 7:36 AM
To: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
Subject: TLM-1 further remarks
 
Sorry to be late on the review feedback. Aside from remarks that have been
already posted by others on the reflector, I am a bit concerned by several
pieces
of text covering TLM-1 that in my opinion would deserve some
clarification.
 
In Section 11.1:
 
11.1.b: ?TLM-1 would typically implement delays by calling wait, which
slows down simulation?.
I don?t question the benefits of TLM-2 on this regard, but this sentence
is not accurate.
 
Our experience of TLM-1 is that we did use transport of timing in the
payload object and are not prevented in any way
to do timing annotation stuff without calling wait() at each timing. Many
actors were aware of these techniques (and using them)
far before TLM-2. It is just that since TLM-1 does not define the payload
object and that timing is not provisioned at interface level,
it does cover interoperability for exchange of timing annotations between
components.
 
To me it would be better to underline the fact that interoperable exchange
of timing annotation is not covered by the TLM-1 standard, which is
factual
(in contrary to ?people would typically don?t know about timing annotation
with TLM-1? which is arbitrary).
 
11.1.c: ?The TLM-1 require all transaction objects and data to be passed
by value or const reference, which slows down the simulation?.
At best, it would be better to rewrite this as ?[...] *potentially* slows
down the simulation?.
For unidirectional uses, I don?t see in which way the TLM-1 interface is
not efficient, since the const reference is as efficient as, say
a TLM-2 interface.
For bidirectional uses, separating the transaction as two data structures
just represent a different choice, which is potentially inefficient
in some context, but clearly not all.
 
On this point, it is maybe more important to avoid these inaccuracies
rather than justifying choices done specifically for memory-mapped buses
in the context of TLM-2.0 and that are orthogonal to other uses where
TLM-2 does not fit.
 
In the same point, ?Some application work around this restriction by
embedded pointers in transaction objects, but this is non-standard,
and non-interoperable?.
 
This cast doubt as to whether having pointers in a TLM-1 payload is even
TLM-1 compliant, in a section that is supposed to address TLM-2.0!
I would request to remove this altogether, and clarifies things in the
TLM-1 section.
 
Which leads us to the TLM-1 section 18 in itself.
 
In section 18.1.1, the newly written text says:
 
?In other words, the transaction object should not contain any pointers or
references to shared memory outside of itself that could be used
to implement back-door communication. If, on the contrary, the transaction
object does include any such pointers or references, then any
subsequent communication through shared memory would be outside the scope
of this standard?.
 
Depending on the way you read these two sentences, you can end up thinking
that having pointers is a bad practice with TLM-1. This would be
ironic, as wherever I turn my head for TLM-1 use, I frequently see
pointers in payloads.
I understand the intent that, if you use pointers, then the TLM-1 standard
in itself does not say anything about pointers ownership rules, but
with the current text, the status of this common practice is just
undefined. Could it be possible to clarify?
 
Thanks,
 
Jerome
 
 
 
 

-- 
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.