RE: Revised Proposal for DMI/Debug extensions

Ok for me :-)

Thanks,

Jerome

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, December 14, 2010 3:51 PM
To: systemc-p1666-technical@eda.org
Subject: 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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.