RE: Proposal for TLM-1 standardization

All-

I think the motivation behind the tlm1:: namespace proposal is to clearly
distinguish tlm1 from tlm2. I think if we are serious about doing this we
should:

1) Put both tlm1 and tlm2 into their own respective namespaces (tlm1:: and tlm2:: )

2) Do it in a way such that there is basically zero backward compatibility issues with current models. Ideally we can somehow have a tlm:: namespace that is the union of everything in the tlm1 and tlm2 namespaces. I don't recall if there is an elegant way to do that in C++ or if we'd have to resort to a brute force include of everything again into the tlm namespace.
If it is too much trouble, then it is probably not worth doing at all. The real mistake here was naming these things tlm1 and tlm2 in the first place, they
should have been something like tlm-MP and TLM-MMAP

-Stuart

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jerome CORNET
Sent: Wednesday, March 10, 2010 1:38 AM
To: john.aynsley@doulos.com
Cc: systemc-p1666-technical@eda.org
Subject: Re: Proposal for TLM-1 standardization

Hello John,

the partitioning between what is kept/what is left out of the standard looks sensible (if we are indeed
forced to leave out parts of TLM-1). I also agree with both your proposal and Stuart's comments
regarding semantics aspects.

However, I am not sure to understand the rationale for renaming the C++ namespace used by TLM-1.
To my knowledge, we don't have any naming conflicts currently between TLM-2.0 stuff and TLM-1
in the official kit released by the OSCI. Currently, people that are using TLM-1.0 just move without
problems to using TLM-2.0 for the memory-mapped bus part of TLM and keep the rest of their
code unchanged. To me, if we are to change this namespace: we will need to release another OSCI TLM
kit with the name change and our users will have to align to this kit version and detect the kit version
to understand whether to use tlm::: or tlm1::. The same will apply for CAD tools already integrating/instrumenting
the OSCI TLM: the user code will have to detect whether that specific version of CAD tools do use tlm1 or tlm
namespace. This does not look reasonable...

Jerome

On 3/9/2010 3:36 PM, john.aynsley@doulos.com<mailto:john.aynsley@doulos.com> wrote:
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.