RE: TLM extensions - GP flags and extensions

Hello Yossi,

this is another possibility with the same principle.
However, in my understanding, it does not cover the response status.

I agree with you, that anyway there is no elegant solution to
make everyone happy :-)

Jerome


From: Veller, Yossi [mailto:Yossi_Veller@mentor.com]
Sent: Thursday, December 09, 2010 4:48 PM
To: Jerome CORNET; john.aynsley@doulos.com
Cc: Bart.Vanthournout@synopsys.com; P1666 Technical WG
Subject: RE: TLM extensions - GP flags and extensions

Hi all,

Wouldn’t solve the backward compatibility issue if the target of a debug call will be obliged to assign zero to the byte enable/streaming width to signify that it used them? I know that it seems somewhat a hack but it seems to me that there are no elegant simple solutions.

Regards
Yossi

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jerome CORNET
Sent: Thursday, December 09, 2010 5: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<http://www.mailscanner.info/>, and is
believed to be clean.

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