RE: New draft LRM available, including TLM-1

Stuart,

Yes, you are right. I have too much SystemVerilog going around in my head
;-)

Re. the zero-length FIFO, I agree the LRM could say the behavior is
undefined (unless anyone raises any strong objections)

John A

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

John-
 
Regarding the first point, since the current tlm_fifo semantics with
size=0 are useless and perhaps someday
will be improved, why not for now in the LRM say that the behavior is
unspecified for size=0.
 
Regarding the second point, I think you may be mistaken. If you look at
the code for tlm_fifo, the ctor
for circular_buffer is:
 
template < typename T >
circular_buffer<T>::
circular_buffer( int size ) {
 
  m_size = size;
  m_buf = new T[m_size];
 
  init();
 
}
 
And the dtor for tlm_fifo does a delete [] of m_buf. So the fifo isn?t
just storing references or handles to transaction
objects, it is storing real objects. It has to ? it could not be
otherwise.
 
I haven?t done the actual experiment, so I may be wrong of course, but I
assume that if you send std::string or a ref counted
transaction thru tlm_fifo you should see the refcounts go to zero when the
tlm_fifo dtor executes.
 
So, assuming I am correct about this, the LRM text needs to reflect it.
 
Thanks
-Stuart
 
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, September 10, 2010 7:03 AM
To: Stuart Swan
Cc: systemc-p1666-technical@eda.org
Subject: RE: New draft LRM available, including TLM-1
 
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.