Revised Proposal for DMI/Debug extensions

Folks,

Here is a revised proposal. Is this acceptable to everybody? Unless there
are objections, I will write this up in the draft LRM.

John A

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

enum tlm_gp_option {
  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_option get_gp_option() const;
void set_gp_option(tlm_gp_option);

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

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

* TLM_FULL_PAYLOAD only applies to the DMI and debug transport interfaces.
For the transport interfaces, "new" initiators shall set the gp_option
attribute to TLM_MIN_PAYLOAD.

* "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_option from TLM_FULL_PAYLOAD to TLM_FULL_PAYLOAD_ACCEPTED

* The value of the gp_option 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. 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_option to
TLM_FULL_PAYLOAD_ACCEPTED if it has the value TLM_FULL_PAYLOAD

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

* "New" initiators that set the gp_option are obliged to set it back to
TLM_MIN_PAYLOAD at the end of the lifetime of the transaction

* Method reset() of tlm_generic_payload shall set the the gp_option 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_option 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
 
  - 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_option 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
gp_option 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). It is not necessarily 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.

* For the DMI interface with the base protocol and gp_option =
TLM_FULL_PAYLOAD, the initiator shall set all attributes other than the
command, address, response status, and extensions to their default values.

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