John, All,
no problem on our side regarding "switching" to rendezvous semantics.
Jerome
On 9/10/2010 4:02 PM, 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>
> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "systemc-p1666-technical@eda.org" <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] *On Behalf Of
> *john.aynsley@doulos.com*
> Sent:* Thursday, September 02, 2010 2:42 AM*
> To:* 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, and is believed to be clean.Received on Tue Sep 14 04:13:53 2010
This archive was generated by hypermail 2.1.8 : Tue Sep 14 2010 - 04:13:57 PDT