Re: Proposal for DMI/Debug extensions

I'm good with this in principle.

On Sun, Dec 12, 2010 at 3:03 PM, <john.aynsley@doulos.com> wrote:

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