RE: Rendezvous semantics for tlm_fifo

Tor,

I meant "implement" in the sense of fully specify the semantics. Of course I agree that it is not the responsibility of the P1666 WG to update the OSCI simulator, but everything non-trivial in the LRM does get prototyped as part of the spec process (even if I have to do it).

Whatever, I am not asking you to change your vote 8=)

John A

-----"Jeremiassen, Tor" <tor@ti.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
From: "Jeremiassen, Tor" <tor@ti.com>
Date: 09/22/2010 12:59PM
Subject: RE: Rendezvous semantics for tlm_fifo

               
  The rendezvous semantics does provide for a possibly useful synchronization primitive. I will vote for B).
   
  John, I don’t think it is really relevant in this forum to consider the “time to implement B)”, as P1666 is not concerned with providing any implementation.
   
  Best regards,
   
  Tor Jeremiassen
   
  
  ---
 Tor Jeremiassen, Ph.D.
 Simulation and Modeling CTO
 SDO Foundational Tools
 Texas Instruments                    Ph:    281 274 3483
 P.O. Box 1443, MS 730                Fax:   281 274 2703
 Houston, TX 77251-1443               Email: tor@ti.com
    
  
  
      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 12:55 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 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, 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.
      

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.