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.