RE: TLM extensions - GP flags and extensions

Exactly. And Philipp and I were looking at refinements to make this more robust by automating it where possible.

John A

-----Bart Vanthournout <Bart.Vanthournout@synopsys.com> wrote: -----
To: Jerome CORNET <jerome.cornet@st.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Philipp A Hartmann <philipp.hartmann@offis.de>
From: Bart Vanthournout <Bart.Vanthournout@synopsys.com>
Date: 12/09/2010 03:41PM
Cc: "Bart.Vanthournout@synopsys.com" <Bart.Vanthournout@synopsys.COM>, "eric.e.roesler@intel.com" <eric.e.roesler@intel.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: TLM extensions - GP flags and extensions

 
In order to make the backward compatibility work we need to make sure that an old initiator in ‘dirty code’ that does not re-initialize the flag before starting a debug transaction doesn’t send out a payload that has the flag set to 1 (the case where the payload was previously used by a new initiator talking to an old-target).
To prevent that my proposal was to require a new initiator to reset the flag to zero after completing the debug transaction.
 
(not sure if I’m clearing things up or further causing confusion at this time…)
Bart
 

From: Jerome CORNET [mailto:jerome.cornet@st.com]
Sent: Thursday, December 09, 2010 4:28 PM
To: john.aynsley@doulos.com; Philipp A Hartmann
Cc: Bart.Vanthournout@synopsys.com; eric.e.roesler@intel.com; P1666 Technical WG
Subject: RE: TLM extensions - GP flags and extensions 
John, all,
 

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, December 09, 2010 4:22 PM
To: Philipp A Hartmann
Cc: Bart.Vanthournout@synopsys.com; eric.e.roesler@intel.com; Jerome CORNET; john.aynsley@doulos.com; P1666 Technical WG
Subject: Re: TLM extensions - GP flags and extensions 
>>Philipp, Bart, Jerome, All,

>>The more I think about it, the more I think changing the core interfaces is a non-starter. Any change would potentially have to be implemented by all custom protocols too.

>>As Bart says, we could have a flag and oblige the initiator to clear it. For GP transactions using a memory manager, we can make this foolproof by clearing the flag in tlm_generic_payload::reset(), effectively getting the same advantages as using auto_extensions. For non-memory-managed transactions, the initiator would have to be responsible for clearing the flag.

I am sorry, but I still don’t understand that part. Can someone explain me?
 
-          An initiator using the extended feature will have to reinitialize the flag because the flag will have been possibly used and incremented.
But, this is not a problem, do we agree?
-          A legacy initiator will no reinitialize the flag at each transaction, but it will not have to, since the flag will remain at its default
value, injected at very first initialization in the gp constructor.
 
Again, what am I missing?
 
Jerome
 

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