RE: Jerome's proposal - RESET

Stuart,

John already answered this one… : the problem exists when reusing transactions for debug where the byte_enable wasn’t reset. In such a case a new target, following Jerome’s rules may assume that the byte_enables make sense. Worst case the byte_enable length is larger than the data_length and you get a crash.
These may be very poorly written models, but they comply with the current rules. I’m not arguing to promote such a coding style either. My only concern is that there would be a backward compatibility issue. I would even accept backward compatibility if there is no other way to solve the problem, but there is and the TLM2.0 standard provides the mechanism through extensions. It may not be the nicest solution, but this wouldn’t be the first time a solution is designed around a backward compatibility issue.

Bart

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Stuart Swan
Sent: Tuesday, December 07, 2010 10:37 PM
To: systemc-p1666-technical@eda.org
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<http://www.mailscanner.info/>, and is
believed to be clean.

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