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.