John,
In my opinion the additional paragraph doesn't help. The other changes are OK.
With TLM2 AT we standardized a reusable modeling style, it can represent certain real life protocols with reasonable accuracy, but only if all models in the simulation silently agree to represent the same protocol...
Just like the mapping from HDL multi-value signals to SystemC signals isn't discussed in the standard, we shouldn't discuss how to map a real life protocol to TLM2 AT...
Bart
From: tlmwg@lists.systemc.org [mailto:tlmwg@lists.systemc.org] On Behalf Of john.aynsley@doulos.com
Sent: Friday, January 14, 2011 12:54 PM
To: Veller, Yossi; P1666 Technical WG; tlmwg@lists.systemc.org; Marcelo.Montoreano@synopsys.COM
Subject: [tlmwg] Revisit of the TLM2.0 phases rules - Proposal
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.Received on Tue Jan 18 00:59:51 2011
This archive was generated by hypermail 2.1.8 : Tue Jan 18 2011 - 01:00:14 PST