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* <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.