RE: Proposal for DMI/Debug extensions

Jerome,

  - [Proposal] The target may set the DMI hint (though the initiator is
free to ignore it)

[JA] Are you okay with this?

* [Tentative proposal] Other values of the gp version attribute are
reserved for future use. It can be assumed that if an initiator sets gp
version >= TLM_FULL_PAYLOAD then the initiator is compatible with
TLM_FULL_PAYLOAD, and if a target sets gp version >=
TLM_FULL_PAYLOAD_ACCEPTED then the target is compatible with
TLM_FULL_PAYLOAD_ACCEPTED. As a consequence, new targets should test "if
gp_version >= TLM_FULL_PAYLOAD" and new initiators should test "if
gp_version >= TLM_FULL_PAYLOAD_ACCEPTED"

I was thinking more to something with independent bit flags that could
have been set independently for each feature, but I realize that your
proposal avoids the many combinations that would arise from these flags,
and indeed simplifies the number of cases and implementation.

[JA] We already have the extension mechanism to deal with multiple
independent features, so I was thinking to make this new mechanism more
like a scalar version number for the base protocol.

* [Tentative proposal] For the DMI interface with the base protocol,
attributes other than command, address, extensions (and now response
status too) currently "need not be set" by the initiator and "may be
ignored" by other components. These attributes are reserved for future use
by the base protocol, so for gp version = TLM_FULL_PAYLOAD or
TLM_FULL_PAYLOAD_ACCEPTED shall not be set by the initiator and shall be
ignored by other components. (This would say nothing about custom
protocols, nor would it place an obligation to update any legacy
components)
Although it seems unlikely that other attributes beside command, address,
extensions and response status will be used, I maintain that leaving some
attributes uninitialized do is a bad practice. Let?s do not repeat the
same mistake here and mandate very explicitly and without additional
clause that could be interpreted as an exception that all attributes needs
to be initialized starting with gp version TLM_FULL_PAYLOAD.

[JA] Yes, agreed, that is better than my proposal. In other words, for gp
version >= TLM_FULL_PAYLOAD, the initiator shall set all generic payload
attributes to their default values (as defined in 15.7)

John A

From:
Jerome CORNET <jerome.cornet@st.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, P1666 Technical WG
<systemc-p1666-technical@eda.org>
Date:
13/12/2010 10:00
Subject:
RE: Proposal for DMI/Debug extensions

John,
 
I accept this proposal in principle.
 
See details and comments below.
 
From: owner-systemc-p1666-technical@eda.org [
mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
john.aynsley@doulos.com
Sent: Sunday, December 12, 2010 10:03 PM
To: P1666 Technical WG
Subject: Proposal for DMI/Debug extensions
 
>>* [Proposal] TLM_FULL_PAYLOAD only applies to the DMI and debug
transport interfaces. In the case of the transport interfaces, the gp
version attribute is reserved for future use, and shall be ignored by all
components in this version of the standard
Agreed.

>>* [Proposal] The value of the gp version attribute shall apply only to
the current transaction instance, and implies nothing about the the
behavior of an initiator, interconnect, or target with respect to other
transactions or to other interfaces. For example, a given initiator may
set TLM_MIN_PAYLOAD and TLM_FULL_PAYLOAD in two consecutive debug
transactions, or may set TLM_MIN_PAYLOAD in a debug transaction and
TLM_FULL_PAYLOAD in a DMI transaction. A target may set
TLM_FULL_PAYLOAD_ACCEPTED for one transaction but not for the next.
[Discussion] A component is expected to inspect each transaction
individually rather than building a map of the initiators and targets it
is communicating with in order to record whether they were "old" or "new"

Good point! I agree with these restrictions. To me, allowing building a
?map? of initiators version would lead to all sort of mechanisms possibly
invented by the user, and this would require to solve the problem of how
to invalidate such maps upon a system remap. Currently we allow implicitly
such maps for DMI, but we do provide the invalidation mechanism that goes
with it.

>> * Old targets may receive DMI/Debug transactions with byte enables and
streaming width set, and will probably ignore them. We are prepared to
live with the risk that the target wrongly interprets those attributes.
Also, a write command may modify bytes that the initiator did not intend
to modify (because they are disabled or have addresses beyond the
streaming width). [Discussion] If we accept the proposal that the
TLM_FULL_PAYLOAD attribute value is per-transaction-instance, it would not
necessarily be possible for an initiator to poll a target to see whether
it supported new-style debug transactions, because a target could anyway
choose on a transaction-by-transaction basis. Moreover, we are not
currently proposing any polling mechanism. An initiator can only determine
after-the-fact that its last transaction may have broken the target.
Agreed.

* [Tentative proposal] Other values of the gp version attribute are
reserved for future use. It can be assumed that if an initiator sets gp
version >= TLM_FULL_PAYLOAD then the initiator is compatible with
TLM_FULL_PAYLOAD, and if a target sets gp version >=
TLM_FULL_PAYLOAD_ACCEPTED then the target is compatible with
TLM_FULL_PAYLOAD_ACCEPTED. As a consequence, new targets should test "if
gp_version >= TLM_FULL_PAYLOAD" and new initiators should test "if
gp_version >= TLM_FULL_PAYLOAD_ACCEPTED"

I was thinking more to something with independent bit flags that could
have been set independently for each feature, but I realize that your
proposal avoids the many combinations that would arise from these flags,
and indeed simplifies the number of cases and implementation.

* [Tentative proposal] For the DMI interface with the base protocol,
attributes other than command, address, extensions (and now response
status too) currently "need not be set" by the initiator and "may be
ignored" by other components. These attributes are reserved for future use
by the base protocol, so for gp version = TLM_FULL_PAYLOAD or
TLM_FULL_PAYLOAD_ACCEPTED shall not be set by the initiator and shall be
ignored by other components. (This would say nothing about custom
protocols, nor would it place an obligation to update any legacy
components)
Although it seems unlikely that other attributes beside command, address,
extensions and response status will be used, I maintain that leaving some
attributes uninitialized do is a bad practice. Let?s do not repeat the
same mistake here and mandate very explicitly and without additional
clause that could be interpreted as an exception that all attributes needs
to be initialized starting with gp version TLM_FULL_PAYLOAD.
 
Thanks,
 
Jerome
 

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