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 A

-----owner-systemc-p1666-technical@eda.org wrote: -----
To: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
From: Stuart Swan
Sent by: owner-systemc-p1666-technical@eda.org
Date: 12/07/2010 09:38PM
Subject: RE: Jerome's proposal - RESET

         
  (resending – due to more reflector issues…?)
   
  Bart (and/or John)-
   
  It seems the major open concern with the “yes and yes” options for the specific votes below is the different views on backward compatibility wrt existing TLM2 models.
  Can one of you describe a few (e.g. 1 or 2) concrete examples where you think there will backward compatibility issues for the specific proposal below?
  This would at least help me in understanding your concerns – maybe also others on the reflector.
   
  Thanks
  Stuart
   
   
  
  From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
 Sent: Tuesday, December 07, 2010 7:54 AM
 To: systemc-p1666-technical@eda.org
 Subject: Jerome's proposal - RESET
     
  Folks,
 
 Since I think I've caused some confusion, let me reset.
 
 I think we have a good understanding of Jerome's proposal re. byte enables, streaming width, and response status for DMI and Debug.
 
 So please vote on the following 2 + 2 options
 
 "No" - no change
 
 "Yes" - make the changes as proposed by Jerome
 
 If "yes", should the LRM wording take the form of a strong recommendation that all models going forward should be written with the proposed changes in mind, and existing models re-written over time? (I am thinking about minimizing compatibility issues going forward by having all components initialize the byte enable, streaming, and response status fields for DMI and Debug and only using those fields ways compatible with the new intent)   YES or NO.
 
 Thanks
 
 John A
    
--
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.