RE: Rendezvous semantics for tlm_fifo

I vote for A) as that is minm. effort.

Thanks,
-Bishnupriya

________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, September 22, 2010 11:25 AM
To: systemc-p1666-technical@eda.org
Subject: Rendezvous semantics for tlm_fifo

All,

We need to close this issue of the semantics of a zero-length tlm_fifo. There are two options on the table:

A) Make the behavior implementation-defined. This means no change to the current code, but a statement in the LRM that users should not rely on the current (rather useless) behavior

B) Change the LRM and the implementation to use rendezvous semantics, i.e. both writer and read may block and wait for one another.

Please vote A) or B). If you don't care, it would probably be best to vote A), because it will take us a little more time and effort to implement B).

Thanks

John A

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: john.aynsley@doulos.com
From: Jerome CORNET <jerome.cornet@st.com>
Date: 09/14/2010 12:13PM
Cc: Stuart Swan <stuart@cadence.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: New draft LRM available, including TLM-1

John, All,

no problem on our side regarding "switching" to rendezvous semantics.

Jerome

On 9/10/2010 4:02 PM, john.aynsley@doulos.com<mailto:john.aynsley@doulos.com> wrote:
Stuart, All,

Re. the tlm_fifo of size 0, I agree that the present semantics are fairly useless and that rendezvous semantics would be better. On the other hand, does anyone care? What do other people think?

Re. the tlm_fifo destructor, since the fifo only stores references to transaction objects whose lifetimes are managed elsewhere, I think it would be very odd if the tlm_fifo destructor interfered with the transaction objects themselves. Just my two cents.

John A

From: Stuart Swan <stuart@cadence.com><mailto:stuart@cadence.com>
To: "john.aynsley@doulos.com"<mailto:john.aynsley@doulos.com> <john.aynsley@doulos.com><mailto:john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org"<mailto:systemc-p1666-technical@eda.org> <systemc-p1666-technical@eda.org><mailto:systemc-p1666-technical@eda.org>
Date: 09/09/2010 00:32
Subject: RE: New draft LRM available, including TLM-1

________________________________

John-

I've read thru your new chapter 18 pretty carefully and it looks very good.

I only found a few things, listed below.

Thanks

Stuart

***

18.1.1 Description

"TLM-1 message-passing, which equates to transaction-passing, is unidirectional."

(Add?: The TLM-1 transport interface can be considered to be composed of two unidirectional

channels which pass separate messages in each direction.)

"In the case of method transport"

<transport needs to be BOLD>

18.3.4 Constructors and destructor

"A bounded fifo may become full, an unbounded fifo cannot become full, and a fifo with size

equal to 0 is both full and empty at the same time such that put and get would each block indefinitely."

<stuart comment: I suppose the description for size 0 is accurate given how tlm_fifo is coded,

but this has always seemed to me to be a bug in tlm_fifo. Maybe it is too late now but I've always thought

that size 0 should imply rendezvous semantics thru tlm_fifo>

virtual ~tlm_fifo();

The destructor shall delete the first-in-first-out buffer but shall not delete any transaction objects

held in the fifo.

<stuart comment: isn't the latter part a bug? ie shouldn't the objects' dtor be called? >

From: owner-systemc-p1666-technical@eda.org<mailto:owner-systemc-p1666-technical@eda.org> [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>
Sent: Thursday, September 02, 2010 2:42 AM
To: systemc-p1666-technical@eda.org<mailto:systemc-p1666-technical@eda.org>
Subject: New draft LRM available, including TLM-1

Folks,

We've made available a new draft LRM that includes the TLM-1 Message Passing Interface (chapter 18).

http://www.eda.org/twiki/pub/P1666/WebHome/1666-2005_Sept_01_10_with_labels.pdf

Please review.

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