Re: [tlmwg] Revisit of the TLM2.0 phases rules

Yossi,

I fully agree with Robert's answers throughout.

From the outset, I have been concerned about the way you seem to be
interpreting 16.2.6 b) and c). Note that these are not "rules" in the
sense that they do not impose any specific obligations. Each TLM-2.0
component is free to make its own modeling decisions and the BP rules
allow quite a bit of flexibility. A BP component can chose how it will use
flow control according to how it wishes to map an actual protocol (e.g.
AXI) onto the BP abstraction. For example, your bus or your target could
return END_REQ immediately and implement any delay internally rather than
bunching the entire 310 NS as BEGIN_REQ->END_REQ delay (in which case it
had better be able to buffer multiple transactions).

You have not written anything that suggest to me that the BP is "broken".
I think you believe the BP is not precisely equivalent to any specific
current standard protocol, and I guess we would all agree, but so what?
The BP is an abstraction, but it IS A PROTOCOL nonetheless, and so any
BP-compliant model has to be written in full knowledge of the protocol
rules.

Also, I am concerned by your statements concerning accuracy expectations
at AT. There are none! Each TLM-2.0 model is free to choose whether to add
a non-zero timing annotation to an outgoing transaction, and how to
interpret a non-zero timing annotation on an incoming transaction (LT
versus AT coding guidelines do not impose any obligations).

Cheers,

John A

-----<tlmwg@lists.systemc.org> wrote: -----
To: "Veller, Yossi" <Yossi_Veller@mentor.com>
From: Robert Guenzel
Sent by:
Date: 01/05/2011 02:16PM
Cc: tlmwg@lists.systemc.org, systemc-p1666-technical@eda.org
Subject: Re: [tlmwg] Revisit of the TLM2.0 phases rules

Hi Yossi,

what you describe in your example is a behavior
where the protocol has shared request and response channels
for reads and writes (because of the BP) but it allows
out-of-order responses (allowed within the BP but not a very common
bus feature).

The OCP can be configured like that and then it would behave exactly
as you described in your examples (both transactions ending around 640ns).

That means (IMHO) that the BP can be used to model a reasonable bus
protocol.
Now if you wanted to bring the BP closer to PLB, OPB, AHB, or APB
(which do not allow out-of-order responses) then
you would have to disallow out-of-order responses. Then your target
would not
be allowed to let the read response overtake the write response.
But that would mean in-order with respect to timing, not only execution
order.

And since we have temporal decoupling at AT, in-order with respect to
timing
would mean to have PEQs everywhere, and that would render the whole idea
of temporal decoupling meaningless (but I confess that I always wondered
if
temporal decoupling at AT is really useful...).
I believe that was one (the?) reason why we decided to allow
out-of-order responses.

So do you agree that the problem is basically just the fact that
responses can overtake
each other? If so, I'd say the BP is the appropriate vehicle to model
reasonable busses,
because nobody forces you to implement your target like you did. You can
easily implement
it such that it keeps the responses in order. Sending out-of-order
responses is an option
not an obligation (whereas tolerating out-of-order responses is
mandatory, but reordering
wouldn't be that hard either).

best regards
  Robert

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