RE: Minor TLM enhancements/fixes

Correction:  the troublesome rule is 15.7 L)

John A

-----John Aynsley/doulos wrote: -----
To: "Jerome CORNET" <jerome.cornet@st.com>
From: John Aynsley/doulos
Date: 12/05/2010 06:58PM
Cc: Bart.Vanthournout@synopsys.com, bpriya@cadence.com, John Aynsley/doulos, "P1666 Technical WG" <systemc-p1666-technical@eda.org>
Subject: RE: Minor TLM enhancements/fixes

Jerome, Bart, All,

I have re-read this entire thread.

Re. if we allow the response status to be used with DMI, the trouble is that there is no guarantee that the response status has been initialized (see below), nor that other components will not use it too for their own devious purposes. An initiator can check the DMI response status, but it cannot absolutely rely on the value it sees, with or without Jerome's proposal. If we assume that existing BP code ignores the DMI response status, then we might not break anything by introducing a new rule that an interconnect/target MAY set the response status. But the better solution would be to use an extension for non-standard signalling.

With debug, Jerome proposes that an initiator MAY set other attributes (i.e. byte enable and streaming width) and that the target SHALL set the response status to OK if it has honored them. In practice, this should be fine most of the time. BUT Bart's point is valid: legacy initiators may leave byte enables set by accident. Jerome quotes rule 15.7.a as saying that every GP attribute must be initialized. But this needs to be qualified by 15.6 l) which says the modifiability rules only apply to the appropriate attributes. (The LRM could be improved here)

Unfortunately, given TLM-2.0 as it stands, I think the right way to treat both the DMI response status and debug byte enables is with extensions. An explicit extension needs to be present to signal extended behaviour. In other words, the initiator should set an extension to signal that it expects a DMI response status or has set debug byte enables, and a downstream component should provide affirmation using that same extension. I think the extensions could be made ignorable (and hence base protocol compliant) in both case.

Having said that, I do appreciate Jerome's position. In my opinion these are good proposals and we could get most of the way to backward compatibility without the need for extensions, but I think extensions need to be used to make things watertight in both cases.

John A

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: Bart Vanthournout <Bart.Vanthournout@synopsys.com>, Bishnupriya Bhattacharya <bpriya@cadence.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
From: Jerome CORNET <jerome.cornet@st.com>
Date: 12/03/2010 09:56AM
Subject: RE: Minor TLM enhancements/fixes

         
  Bart,
   
  comments below.
   
  
  
  From: Bart Vanthournout [mailto:Bart.Vanthournout@synopsys.com]
 Sent: Thursday, December 02, 2010 6:48 PM
 To: Jerome CORNET; Bart Vanthournout; Bishnupriya Bhattacharya; john.aynsley@doulos.com; P1666 Technical WG
 Subject: RE: Minor TLM enhancements/fixes
       
   
>>Regarding 12.2.4.k): clearly there is no additional backward compatibility introduced, since there is no change to the standard. But that  >>means I do not see the value of the clarification, I’m worried it might cause confusion and that users may start to think something should or >>will be done with the response attribute and incorrectly expect that this is the advised way to use this API…
   
  You are right, and again I apologize for my probably inadequate english wording. This is a matter of “should/could/shall” that John is able to resolve far better than me. I think however you got the idea: this is backward compatible, and this defines clearly optional ways of giving an information about the reason why a transaction performed on these DMI and Debug interfaces actually failed. This optional ways are left in a completely grey area of the standard prior to this modification, hence the added value.
   
>>Regarding 12.3.4.o): here there is a change to the standard; there is an expectation that if an initiator uses byte_enables that it can rely on >>the response_status. This is an issue for initiators that reuse a payload from a previous transport call, in this case streaming_width or >>byte_enables might have been set, causing an incompatibility with the extended rule. Rule 12.3.4.p) states that reuse of payloads is >>allowed, this would no longer be the case (or at least it would have different implications than today).
>>I would not want to make this change, in this case because of the potential backward compatibility issues.
   
  Indeed, if an initiator uses the extended rule, it will need to rely on the response status. But the only value that it can rely upon is TLM_OK_RESPONSE. All other values, typically returned by targets not aware of that rule (as current TLM-2 models are) will be considered as “the transaction with the use of extended rule has not been understood”. Hence backward compatibility.
   
  Now, you are envisaging the particular situation where a transaction with byte enable/streaming width set to a non-default value would be reused from a previous transport call to be sent through the debug interface. If I understand well, in this case, you would expect the old byte enable/streaming width to be ignored by the target. I don’t clearly understand the benefits of not reinitializing these attributes to their default value in the initiator before sending the transaction (simulation speed??) but I can point to you many disadvantages and definitely agree with Stuart that this is bad practice:
  -��������� You will possibly have in the GP a byte enable pointer resolving to an area of memory that is no longer valid at the moment of the call. Hardly a good practice; consider that that byte enable pointer could be used by say, a buggy target. You will end losing more and more time debugging the buggy target.
  -��������� Current 12.3.4.o section says
the target and any interconnect component may ignore all other attributes
. Correct my reading of english, but ^ay�does not imply that all targets and interconnect components
will�indeed ignore all other attributes. A well written TLM-2 initiator model would better set these attributes to a neutral value (such as the default value)...
  �
  However, this is not only a matter of bad practice. The initiator you describe is just not TLM-2 compliant:
  rule 15.7.a clearly states that
it is the responsibility of the initiator to set the value of every generic payload attribute [...] prior to passing the transaction object through an interface method call.��o:p>
  Please note that section 15 is the section covering the generic payload (independently of the interface method call used, as the wording above implies). In addition the rule talks about *every* generic payload attribute regardless of their ignorability.
  �
  This is what makes me confident that the backward compatibility situation you pointed to is not even theoretical, it is just not compliant with the actual standard.
  �
  �
  Best regards,
  �
  Jerome
  �
  �
    
  

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