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.