(resending, since it seems to not have gone thru)
John, All-
I think you should put these items up for a vote.
I vote yes on them. I’m in agreement with you that these enhancements are “a good thing”, and I also agree that the argument on both sides are not black and white.
Where I differ is in yours and Bart’s rather extreme concerns about backward compatibility. It seems to me that these concerns are overblown, and that even if such legacy models existed that exhibited the backward compatibility issues, we’d all agree that they were poorly written.
Also, I think we are making a mistake in viewing the OSCI TLM2.0 LRM as “perfect”. In reality there are remaining HUGE open issues (e.g. endianness handling) with the OSCI TLM 2.0 LRM and there are all kinds of models being developed out there that claim TLM2.0 compliance when in fact they are not.
I think the kind of reasonable (and very minor) evolution of the standard that Jerome is proposing makes sense, and I imagine there will be more of it in the future.
Thanks
Stuart
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Monday, December 06, 2010 7:42 AM
To: Jerome CORNET
Cc: Bart.Vanthournout@synopsys.com; Bishnupriya Bhattacharya; john.aynsley@doulos.com; P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes
Jerome, All,
Well said.
The TLM-2.0 LRM says that for DMI and Debug,
1) a BP initiator is not obliged to initialize any of the attributes under discussion, and that
2) any BP component is free to totally ignore the values of those attributes
So as things stand, you can have your BP components use the byte enables and response status with DMI and debug so long as you accept that every component is free to totally ignore these attributes. This is the basis for BP extensions in TLM-2.0 as things stand.
I think the enhancements you want to add would be a good thing, and I agree the argument is not black-and-white, but personally I have to vote "no" at this point.
John A
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Dec 6 10:17:26 2010
This archive was generated by hypermail 2.1.8 : Mon Dec 06 2010 - 10:17:28 PST