RE: Proposal for TLM-1 standardization

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 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, and is 
believed to be clean. 
-- 
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.