Re: Proposal for TLM-1 standardization

Agreed, good idea. We could have a <tlm> with tlm1:: and tlm2::, and the
plain
old tlm.h containing everything in tlm:: without backward compatibility
issues.

Jerome

On 3/11/2010 6:22 PM, john.aynsley@doulos.com wrote:
> Agreed. If nothing else, I'm sure we could achieve this with separate
> includes (cf. <systemc> and <systemc.h>)
>
> JOhn A
>
>
> From: Stuart Swan <stuart@cadence.com>
> To: Jerome CORNET <jerome.cornet@st.com>, "john.aynsley@doulos.com"
> <john.aynsley@doulos.com>
> Cc: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date: 10/03/2010 21:47
> Subject: 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.