Re: Revisit of the TLM2.0 phases rules - Proposal

All,

There has been no enthusiasm for the changes below, so I withdraw the
proposal. No change for P1666.

John A

From:
john.aynsley@doulos.com
To:
"Veller, Yossi" <Yossi_Veller@mentor.com>, "P1666 Technical WG"
<systemc-p1666-technical@eda.org>, tlmwg@lists.systemc.org,
Marcelo.Montoreano@synopsys.com
Date:
14/01/2011 11:55
Subject:
Revisit of the TLM2.0 phases rules - Proposal
Sent by:
owner-systemc-p1666-technical@eda.org

All,

This email is directed at the P1666 WG, but I am copying the TLM WG.

Having followed the whole of this thread, it seems there is no consensus
to change the base protocol rules at this point (with respect to the
response exclusion rule), but there does seem to be a view that 16.2.6 b)
and c) could be clearer. To me, the phrases "notionally", "it would be
natural", and "is not obliged to do so" make it clear that these
paragraphs are explanatory in nature and do not impose specific
obligations. But evidently it is possible to misread the intent.

So, with some trepidation, I propose the following rewording.

b) For a write command, the BEGIN_REQ phase marks the beginning of a time
window during which the data becomes available for transfer from initiator
through interconnect component to target. Notionally, the transition to
the BEGIN_REQ phase may correspond to the start of the first beat of the
data transfer. It is the responsibility of the downstream component to
calculate the transfer time, and to send END_REQ back upstream when it is
ready to receive the next transfer. It would be natural for the downstream
component to delay the END_REQ until the end of the final beat of the data
transfer, but it is not obliged to do so. The downstream component has the
freedom to advance or delay the END_REQ in order to achieve the desired
flow control.

c) For a read command, the BEGIN_RESP phase marks the beginning of a time
window during which the data becomes available for transfer from target
through interconnect component to initiator. Notionally, the transition to
the BEGIN_RESP phase may correspond to the start of the first beat of the
data transfer. It is the responsibility of the upstream component to
calculate the transfer time, and to send END_RESP back downstream when it
is ready to receive the next transfer. It would be natural for the
upstream component to delay the END_RESP until the end of the final beat
of the data transfer, but it is not obliged to do so. The upstream
component has the freedom to advance or delay the END_RESP in order to
achieve the desired flow control.

New para) Each component has the freedom to map any additional phases (for
example, address decoding and arbitration) onto the phases of the base
protocol in any manner it chooses, with the consequence that the timing
accuracy of the base protocol is fundamentally limited to that achievable
using the abstraction of just four timing points closely tied to two flow
control rules.

Does that work for everyone, or does it just dig the hole deeper?

Cheers,

John A

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