Proposal for DMI/Debug extensions

Folks,

Below I have fleshed out the proposal to add extended DMI and Debug behavior to the generic payload. I have proposed possible solutions to a few open issues, and would welcome feedback.

Also, please "vote" now whether you would accept or oppose this proposal in principle (before we waste time fine-tuning the detail)

Thanks,

John A

* Add one new attribute (a private member) to tlm_generic_payload, with type

enum tlm_gp_version {
  TLM_MIN_PAYLOAD = 0,  // Default
  TLM_FULL_PAYLOAD = 1,
  TLM_FULL_PAYLOAD_ACCEPTED = 2
}; 

* Add new public methods to tlm_generic_payload to get and set this attribute

tlm_gp_version get_gp_version() const;
void set_gp_version(tlm_gp_version);

* "Old" initiators that are not aware of the gp version attribute will by default leave it as TLM_MIN_PAYLOAD. Base-protocol-compatible components may ignore the gp version attribute

* "New" initiators that use the full set of generic payload attributes for debug or that expect a response status shall set the gp version to TLM_FULL_PAYLOAD

* [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

* "New" targets that use the full set of generic payload attributes for debug or that return the full set of response status values shall change the gp version from TLM_FULL_PAYLOAD to TLM_FULL_PAYLOAD_ACCEPTED

* [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"

* Targets are only permitted to set the gp version to TLM_FULL_PAYLOAD_ACCEPTED if it has the value TLM_FULL_PAYLOAD (or >= TLM_FULL_PAYLOAD - see below)

* An interconnect shall not set the value of the gp version (except when it is acting as a target in order to return an error response)

* "New" initiators that set the gp version are obliged to set it back to TLM_MIN_PAYLOAD at the end of the lifetime of the transaction (whether it has the value TLM_FULL_PAYLOAD or TLM_FULL_PAYLOAD_ACCEPTED)

* Method reset() of tlm_generic_payload shall set the the gp version to TLM_MIN_PAYLOAD such that it will automatically be reset in the presence of a memory manager

* For the debug interface, targets that set the gp version to TLM_FULL_PAYLOAD_ACCEPTED are obliged to check the full set of generic payload attributes as per the transport interface (including byte enables and streaming width), and if unable to honor them, shall generate a Standard Error Response (through the response status or the report handler).

  - The default value of streaming width is 0, but a streaming width of 0 shall be invalid when a transaction is sent (as per the transport interfaces)

  - A null byte enable pointer means byte enables are not used, in which case the byte enable length shall be ignored
 
  - A non-null byte enable pointer means byte enables are used, and byte enable length shall be > 0
 
  - The modifiability rules for the existing generic payload attributes shall be as per the transport interfaces
 
  - [Proposal] The target may set the DMI hint (though the initiator is free to ignore it)
 
* For the DMI and debug interfaces, targets that set the gp version to TLM_FULL_PAYLOAD_ACCEPTED may set the response status to its full range of values as for the transport interface, in which case initiators shall interpret the response status as per the transport inteface . If the attribute is TLM_MIN_PAYLOAD, targets shall not set the response status.
 
* 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.

* [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"

* [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)

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