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.