RE: Jerome's proposal - RESET

Sorry, I meant to type "Sending such a transaction through Debug is a corner case"

-----owner-systemc-p1666-technical@eda.org wrote: -----
To: "Stuart Swan" <stuart@cadence.com>
From: john.aynsley@doulos.com
Sent by: owner-systemc-p1666-technical@eda.org
Date: 12/08/2010 04:52AM
Cc: john.aynsley@doulos.com, "P1666 Technical WG" <systemc-p1666-technical@eda.org>
Subject: RE: Jerome's proposal - RESET

Stuart,

Re. TLM_OK_RESPONSE, I agree that the "old" initiator does not care.

Whether or not this scenario is unlikely, it can happen. I think pooled transactions are the norm. The use of byte enables may be the minority case, but it exists. Sending such a transaction through DMI is a corner case, but will happen occasionally. I do not buy the argument about poorly written models. The world is full of poorly written models, and anyway not initializing all the transaction attributes for DMI+Debug is explicitly permitted by the LRM. If someone has solid evidence that such models do not exist, I would have to concede the point.

(Again, I think these changes are good, but one could explore several possible safe mechanisms for accomplishing them without the risk of corner-case bugs, e.g:
- An ignorable extension
- A new field in the GP containing the protocol version
- A new initial value for the response status)

Just my opinion ;-)

John A

-----Stuart Swan <stuart@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Stuart Swan <stuart@cadence.com>
Date: 12/08/2010 03:36AM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: Jerome's proposal - RESET

         
  John, All-
   
  Just a bit of thinking out loud here:
   
  For DMI and Debug I’m don’t see a concern if TLM_OK_RESPONSE has been previously set via a pooled transaction, since we only need to worry if the inititiator is actually going to check the response value, but if that is the case it is now a “new” initiator rather than an “old” initiator so the backward compatibility concern does not apply.
   
  It seems that it is true that an old initiator and a new target may get into trouble if a pooled transaction from the initiator has garbage settings for byte enable and streaming width and the target acts on them (unbeknownst to the initiator), but that seems like a pretty unlikely scenario, and surely a poorly written model in any case.
   
  Does that make sense?
   
  Thanks
  Stuart
   
  
  From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
 Sent: Tuesday, December 07, 2010 6:39 PM
 To: Stuart Swan
 Cc: P1666 Technical WG
 Subject: RE: Jerome's proposal - RESET
     
  Stuart, All,
 
 The key LRM clauses are
 
 12.2.4 k)
 12.3.4 o)
 15.7 l)
 
 With an "old" initiator and a "new" target, the initiator may have pooled transactions with any of the GP attributes set (e.g. response_status = TLM_OK_RESPONSE is likely), and may send them as DMI or Debug transactions without initializing those attributes. Whatever the argument about good vs bad coding style, TLM-2.0 does not oblige an initiator to reset these attributes for DMI/Debug, so there will be examples out there somewhere. A "new" target would misinterpret these attributes. This is my only specific backward compatibility concern.
 
 John
  
     
        

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

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