RE: Proposal for TLM-1 standardization

Tor-

tlm1 transport() is definitely in use in industry. Since tlm1 is message passing,
with transport, since the communication is bidirectional, you have two messages,
and the separate template parameters give you the option of having distinct message
types. If you want the message types to be the same you can just use the same parameter.

-Stuart

From: Jeremiassen, Tor [mailto:tor@ti.com]
Sent: Wednesday, March 10, 2010 3:13 PM
To: Stuart Swan; john.aynsley@doulos.com; systemc-p1666-technical@eda.org
Subject: RE: Proposal for TLM-1 standardization

John, Stuart,

I have a quick question about the tlm_transport_if. This is an interface that is templated on two types, a request type and a response type. This to me seems to force a level of asymmetry on the user that never intuitively appealed to me. Is this interface broadly used today as far as you (or anyone) knows? Just curious.

Tor

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Stuart Swan
Sent: Tuesday, March 09, 2010 5:05 PM
To: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
Subject: RE: Proposal for TLM-1 standardization
John-
This looks like a reasonable proposal to me. I think the stuff you propose to include & exclude
looks fine.
With regards to semantics & intent & "obligations", I think we should document that the intent and recommended usage
is pure message passing, which means that transaction types are obligated to have proper copy ctors,
assignment operators, destructors,  etc., which adhere to "a copy is as good as the original / deep copy" semantics.  For example, int, std::string,
and std::vector<int> have these semantics.
Although it is not recommended by the standard,
if users wish to use types with tlm1 interfaces which do not have such semantics (e.g. char*, struct foo { int *i; }, then
it is left up to the user to insure that the caller/callee of the tlm1 apis adhere to some protocol (not specified by the tlm1 standard) that
provides proper copy semantics. For example "recipient of data must copy on write, copy on store" can be used as a protocol to provide such
semantics if pointers/handles are being passed.
-Stuart
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, March 09, 2010 6:37 AM
To: systemc-p1666-technical@eda.org
Subject: Proposal for TLM-1 standardization
Folks,
Re. TLM-1, I tentatively propose we standardize the following (only).
Apart from the tlm_analysis_triple, this proposal reflects the contents of the OSCI TLM-2.0 LRM, and so already has at least tacit approval from the SystemC community.
I have excluded tlm_delayed_analysis_if and tlm_analysis_triple because
a) that technique of timing annotation for transaction logging has not been adopted in the SystemC community (as far as I know - please correct me) and
b) they are used neither by OVM nor by VMM 1.2.
Rename the core interfaces to become the "TLM-1 Message Passing Interface"
Rename the C++ namespace from tlm to tlm1
Standardize the following interfaces and classes (details as per the TLM-2.0.1 distribution)
tlm_tag
tlm_transport_if
tlm_blocking_get_if
tlm_blocking_put_if
tlm_nonblocking_get_if
tlm_nonblocking_put_if
tlm_get_if
tlm_put_if
tlm_blocking_peek_if
tlm_nonblocking_peek_if
tlm_peek_if
tlm_blocking_get_peek_if
tlm_nonblocking_get_peek_if
tlm_get_peek_if
tlm_fifo_put_if
tlm_fifo_get_if
tlm_fifo_debug_if
tlm_fifo
tlm_write_if
tlm_analysis_if
tlm_analysis_port
tlm_analysis_fifo   (but excluding the tlm_analysis_triple)
Exclude the following items
tlm_blocking_master_if
tlm_blocking_slave_if
tlm_nonblocking_master_if
tlm_nonblocking_slave_if
tlm_master_if
tlm_slave_if
tlm_fifo_config_size_if
tlm_nonblocking_put_port
tlm_nonblocking_get_port
tlm_nonblocking_peek_port
tlm_event_finder_t
tlm_req_rsp_channel
tlm_transport_channel
tlm_transport_to_master
tlm_slave_to_transport
tlm_delayed_write_if
tlm_delayed_analysis_if
tlm_analysis_triple
Standardize the following
Intent of the TLM-1 message-passing interface and the request/response arguments to transport  (as compared with TLM-2.0)
Meaning of blocking vs non-blocking vs analysis interfaces
Semantics of put, get and peek with respect to moving transactions around (
        put does not overwrite the previous put,
        get returns a different transaction each time,
        successive calls to peek return identical transactions,
        and so forth)
Semantics of blocking and non-blocking interfaces with respect to success/failure and the true/false return value
Semantics of write with respect to blocking and ordering (non-blocking, order undefined)
Obligations on caller and callee with respect to setting, modifying and reading method arguments
Obligations and assumptions with respect to the lifetime of transaction objects
Intent with respect to embedding pointers and references within the transaction object
Behavior of tlm_fifo, tlm_analysis_port and tlm_analysis_fifo
Comments?
--
John A
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.