RE: TLM extensions - GP flags and extensions

Hi Jerome,

 

You are right this does not cover the response status, so let me try some more:

 

As for the byte enable/streaming width my proposal

“The target of a debug call will be obliged to assign zero to the byte enable/streaming width to signify that it used them”

solves the new initiator / old target compatibility issues.

 

If we add a new error status enum value and advise the new initiators to initialize the error status to it for debug and DMI calls, we can solve the following:

 

A. The old initiator/new target compatibility issues because the new target will consider the byte enable/streaming width only if it sees the new error status enum value.

 

B. The response status:

1. The LRM will mandate returning status for debug and DMI calls.

2. A new initiator will be able to react upon error status of new target/interconnect (it will be changed from the new error status enum value).

 

My proposal avoids adding attributes to the GP (minimizing the number of attributes was a goal of the TLM group).

 

What do you think?

 

Regards

Yossi

 

From: Jerome CORNET [mailto:jerome.cornet@st.com]
Sent: Thursday, December 09, 2010 6:01 PM
To: Veller, Yossi; john.aynsley@doulos.com
Cc: Bart.Vanthournout@synopsys.com; P1666 Technical WG
Subject: 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.