Re: TLM extensions - GP flags and extensions

Yossi,

although your proposal avoids the addition of an explicit new attribute
to the GP, there's still the same problem with transaction pools.

  Any new initiator still needs to reset the response_status after the
transaction has finished, to avoid leaks of the TLM_INIT_DBG_DMI value
to new targets via an old initiator.

  That said, I think an explicit attribute is cleaner than encoding a
protocol detail in the response_status.

My 2¢,
  Philipp

On 10/12/10 16:21, Veller, Yossi wrote:
> 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
>
>
>
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.