RE: Jerome's proposal - RESET

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Wednesday, December 08, 2010 5:52 AM
To: Stuart Swan
Cc: john.aynsley@doulos.com; P1666 Technical WG
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.

John, all,

I don’t want to argue forever on this topic, but let us just note that I disagree with your statement
that “not initializing all the transaction attributes for DMI+Debug is *explicitly* permitted by the LRM”.

I recognize, as I did before, that there is a grey area on whether the LRM requires all attributes to be initialized.
However, we are far from having the LRM to explicitly allow that. Why am I saying that?


- Section 15.7.a tells the reader that “It is the responsibility of the initiator to set the value of *every* generic payload attribute

prior to passing the transaction through an interface method call”.

- Section 15.7.l tells the reader that in the case of Debug and DMI, “the modifiability rules given in this section shall apply to the appropriate attributes” (that is the limited subset of attributes currently explicitly used: command, address, etc. but not streaming width, byte enable, etc.).


I don’t pretend being an expert with the standard, but I read it very often for my work, and I participated in its inception. I can tell you that this is not so clear that these two clauses allow *not initializing* all the attributes.

What is intended as “modifiability rules” ? If you look at table 53, you have got default values and modifiability clearly separate. 15.7.a seems to go with “Default values”, whereas “modifiability” seems to go with rules that regards the ability for an interconnect or a target to indeed modify a generic payload attribute (for instance, it is forbidden for an interconnect to modify the data array and so on).
Then, if you look at 15.7.b, you see that “The modifiability rules would apply afresh were the transaction object to be re-used for a new transaction”. But does it apply to payload reinitialization or not? Who knows...

My point is not trying to argue that the standard explicitly mandate every payload’s attribute initialization. But I just want to remind you
that from the point of view of someone who had not written the standard, this is far from explicit. And a vast majority of programmers, given the doubt, will not rely on such implicit assumptions.
In addition, you recognize by yourself that the 15.7.l “could be improved”. I don’t see why it should be improved if it is so explicit...


I am sorry to say that, as I see the situation, some people in this group are trying to block a general-use improvement under the pretext of backward compatibility. Digging deeper (and trying to actually address these concerns), it happens that these concerns are either on hypothetical cases or in very clear cases of bad programming practices from the point of view of debugging, implementing grey areas of a standard, and so on.

We are trading the improvement of the standard for backward compatibility with “poorly written models” (in John’s own words).

This is unfortunate, and I am glad we did not did that reasoning for other SystemC features, else we would have gone nowhere.
We would still be arguing on some existing models relying on the strange value of sc_time_stamp() on return of sc_start() after
event starvation, to only name one example.

TLM-2 is then probably perfect as is, with proprietary extensions solving all interoperability problems, including the ones that
touch the very core of the standard. I am eager to see the upcoming questions in the TLM Working Group when people will start
to stumble on perfection... (this has already started btw).

Thanks,

Jerome

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