RE: TLM extensions - status

From: <john.aynsley@doulos.com>
Date: Thu Dec 09 2010 - 07:30:16 PST

Jerome,

WHOOPS! That point is central to the backward compatibility argument, so perhaps we have been talking at cross-purposes all along.

A new initiator will reset the flag, but an old initiator will not reset the flag because it does not know it exists. Why does the the old initiator not get a new transaction with the flag at its default value of 0 anyway? Because it may be getting the transaction from a pool, where the transaction attributes will have values left over from a previous life. Hence the recent proposals for mechanisms to automatically reset the flag (and why auto extensions would have been an out-of-the-box solution if only a memory manager were mandated, which it is not).

John A

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "Philipp A. Hartmann" <philipp.hartmann@offis.de>
From: Jerome CORNET <jerome.cornet@st.com>
Date: 12/09/2010 11:39AM
Cc: Stuart Swan <stuart@cadence.com>, Bart Vanthournout <bartv@synopsys.com>, "stanleyk@cadence.com" <stanleyk@cadence.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: TLM extensions - status

         
   
  
  
  From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
 Sent: Wednesday, December 08, 2010 10:01 PM
 To: Philipp A. Hartmann
 Cc: john.aynsley@doulos.com; Stuart Swan; Bart Vanthournout; Jerome CORNET; stanleyk@cadence.com; P1666 Technical WG
 Subject: Re: TLM extensions - status
       
>>Good point. The new init would be obliged to reset the flag, which could be done in the mem mgr, but it is not v robust. An >>extension would be safer, or Erics proposal...
 
 
 
  Sorry, I think I missed the point. A new initiator will have to reset the flag (but this is not as big deal, it must
  do something to benefit the extra feature); an old initiator will not have to reset anything, and its payloads
  will have the default value for the attribute.
  What am I missing?
  
 Jerome
   
    

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Dec 9 07:30:55 2010

This archive was generated by hypermail 2.1.8 : Thu Dec 09 2010 - 07:30:57 PST