RE: TLM extensions - GP flags and extensions

Hi Jerome,

 

The new ENUM value, let us call it TLM_INIT_DBG_DMI, is used by an initiator to initialize the error status filed and thus signify that it is a “new initiator”.

A new target will override this value by OK or by any address/burst/byte enable errors (it does not return TLM_INIT_DBG_DMI).

 

The real use of TLM_INIT_DBG_DMI is to tell the target that the values of the byte enable/streaming width are genuine and not just left-overs from GP reuse.

 

Regards

Yossi

 

From: Jerome CORNET [mailto:jerome.cornet@st.com]
Sent: Friday, December 10, 2010 1:28 PM
To: Veller, Yossi; john.aynsley@doulos.com
Cc: Bart.Vanthournout@synopsys.com; P1666 Technical WG
Subject: RE: TLM extensions - GP flags and extensions

 

Hi Yossi,

 

indeed this shows another way of doing it: adding things to the current ENUM attribute (which

is expandable indeed).

 

However, I don’t understand one point: how to make the difference between say, address/burst/byte enable errors if we return

the new enum attribute?

 

There were original goals of the TLM group to minimize the number of attributes to avoid

everyone put its favorite bus attribute (locking, security, whatever) and dig ourselves in endless

conflicts between the various possible attributes.

However, we are not in the same context here. We are proposing to add a new attribute that is not

a bus attribute, but one to resolve issues with the current base protocol attributes.

In addition, it seems we can possibly converge with new ideas from Philipp to make a more

generic mechanism to provision similar situations in the future.

 

 

Jerome

 

From: Veller, Yossi [mailto:Yossi_Veller@mentor.com]
Sent: Thursday, December 09, 2010 5:51 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 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

 

 

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