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.