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

Hi Robert,

Thanks for your correction to the example. However we both agree that
the mistake does not change much.

In TLM2.0 we are not on solid ground because ASFAIK there are no claims
about the abilities of the TLM2.0 rules.
However I assumed that an implicit claim specifies that, unless it as a
part of the application requirements, the rules will not cause an
arbitrary change in the order of the events to change the timing by 100%
(can be more for examples with more initiators). It also should be true
that a delay of a cycle or a Pico second should not change the timing by
100% due to the rules.

My target and bus try to finish the transfers as fast as possible and
still the timing results vary because of the rules and events order.
T answers as fast as it can, it does not have to consider the fact that
allowing the read response to overtake the outstanding write response
will just double the time (this is an artifact of the rules and not the
application).
There is no rule that forces a bus to work deterministically, and if
there was one (e.g. by waiting a cycle as you proposed and choosing
always the same request), I could delay one BEGIN_REQ by a cycle, and
show that just a cycle delay causes the same misbehavior.

What you presented as the purpose of the simulation is just, in this
case, concentrating on how to achieve some workaround to the TLM2.0
rules and not to achieve the application results. Writing applications
with AT is hard enough without considering all the time the artificial
effects of the TLM2.0 rules.

Unless you want to construe rules that will make such scenarios as I
presented impossible (which I suppose that you can't or that they will
be inacceptable), I see the current base protocol as broken.

Regards
Yossi

> -----Original Message-----
> From: tlmwg@lists.systemc.org [mailto:tlmwg@lists.systemc.org] On
Behalf Of
> Robert Guenzel
> Sent: Wednesday, January 05, 2011 10:54 AM
> To: tlmwg@lists.systemc.org
> Cc: systemc-p1666-technical@eda.org
> Subject: Re: [tlmwg] Revisit of the TLM2.0 phases rules
>
> My comments are in-line below
>
> Veller, Yossi wrote:
> >
> > I tried to have the shortest example and maybe it was a mistake. So
> > let me try again:
> >
> > Let us look at two initiators I1 and I2 connected to a bus B and
target T.
> >
> > I1 writes to T a burst whose data transfer should take 310 NS and
the
> > time END_REQ->BEGIN_RESP should take 10 NS.
> >
> > I2 reads from T a burst whose data transfer should take 311 NS and
the
> > time END_REQ->BEGIN_RESP should take 9 NS
> >
> > Both start at the same time (t1).
> >
> > Let us denote the generic payload (GP) from I1 GP1 and the GP from
I2 GP2
> >
> > t= t1 I1 sends GP1(BEGIN_REQ) to B
> >
> > B passes the GP1(BEGIN_REQ) to T
> >
> > T computes that the written data takes 310 NS (because of rule
16.2.6
> > b) and waits.
> >
> > I2 sends GP2(BEGIN_REQ) to B, B queues it in a PEQ (because of the
> > BEGIN_REQ rule 16.2.6 e).
> >
> > t= t1+310 NS T sends GP1(END_REQ) and B passes it to I1 then B takes
> > GP2(BEGIN_REQ) from the PEQ and calls T.
> >
> > T returns TLM_UPDATED and changes the phase to END_REQ and B sends
> > GP2(END_REQ) to I2.
> >
> > t= t1+319 NS T sends GP2(BEGIN_RESP) and B passes it to I2.
> >
> > I2 computes that the read data takes 311 NS (because of rule 16.2.6
c)
> > and waits.
> >
> > t= t1+320 NS T sends GP1(BEGIN_RESP) and B pushes it into the PEQ
> > (because of the BEGIN_RESP rule16.2.6 f).
> >
> No. T does not send BEGIN_RESP here. It can't. Due to the END_RESP
rule.
> >
> > t= t1+640 NS I2 sends GP2(END_RESP) and B passes it to T (and the
read
> > finishes)
> >
> > B sends the GP1(BEG_RESP) to I1 which replies with TLM_COMPLETED
> >
> > B sends the GP1(END_RESP) to T (and the write finishes)
> >
> After getting the END_RESP with GP2, T will now send BEGIN_RESP which
will
> finish with TLM_COMPLETED.
> That doesn't change much, but the example should not violate the rules
> it questions.
> >
> > Here I arranged the time so that your points about the behavior of T
> > do not hold (It now has only one alternative). We've got to the same
> > result. The added delays were forced by the TLM rules and not by any
> > of the models.
> >
> And it seems perfectly correct to me. Read and writes share the same
> request and response channels.
> T allows the read response to overtake the outstanding write response.
> By that it accepts that now the write can
> only finish when the read response has finished. If that is not
desired
> T will have to schedule the read response
> behind the write response. that will increase the END_REQ->BEGIN_RESP
> delay from the desired 9ns
> to (at least) 10 ns (plus a potential BEGIN_RESP->END_RESP delay in
the
> write),
> but that is the whole purpose of the simulation, right? If everything
> was independent
> from everything else, well then you can simply calculate how long
things
> will take and you do not need
> to simulate anything.
> >
> > However if the simulator chooses to schedule I2 before of I1 the
whole
> > operation will take only 320 NS.
> >
> And in my opinion that is a problem of B. Two things happen at the
same
> time in a simulation.
> Apparently B is using some kind of combinatorial arbitration because
it
> directly forwards
> an incoming BEGIN_REQ to T. When doing that it should employ a
mechanism
> that allows it
> to make deterministic choices. It could use some kind of delta cycle
> waiting or whatever to make
> sure that the BEGIN_REQs from I1 and I2 both have arrived and it can
> then forward the correct one.
> In this case the simulation order of I1 and I2 will not effect the
> resulting communication order anymore.
>
> If such a mechanism is not desired at AT, because it effects
simulation
> speed, then you must accept that
> your AT model is execution order dependent.
> >
> > So do you agree that the rules are broken?
> >
> No (not yet). And I try to explain my view below.
> >
> > Besides this: I don't agree with your points about the broken
target,
> > there is no rule that forces T to respond with TLM_UPDATED and not
> > TLM_ACCEPTED even though the first is more efficient. The TLM rules
> > should enable deterministic timing regardless of such choices of the
> > target (or initiator or bus) behavior as long as their communication
> > complies with the rule and they try to achieve their separate
timing.
> >
> And I disagree. In my opinion the choices should have an effect on
timing.
> If I (a target) return TLM_ACCEPTED to BEGIN_REQ I disallow a
subsequent
> BEGIN_REQ at the same time,
> if I return TLM_UPDATED with END_REQ I allow it (even if I increase
the
> timing annotation).
> If I return TLM_UPDATED with BEGIN_RESP I also allow a subsequent
> BEGIN_REQ, but
> I also make clear that the response cannot be overtaken by any other
> response.
> If I return TLM_COMPLETED I disallow any other delays. The initiator
has
> no chance of
> adding some BEGIN_RESP->END_RESP delay.
>
> Similar things apply to the choice if I skip END_REQ or not.
>
> It is obvious that those choices control what a connected bus or
> initiator can do to me.
> That is the whole purpose of flow control. If the choices would not
> effect timing
> than the question would be why there are choices at all.
>
> To explain that a little more:
> Let's say we have
> nb_trans_fw(gp1, BEGIN_REQ, t)
> and I wanna send an END_REQ in 10 ns
>
> now I can do
> option 1:
> return TLM_ACCEPTED; wait(10 ns); send nb_trans_bw(gp1, END_REQ, 0s)
> option 2:
> t+=10ns;
> ph=END_REQ;
> return TLM_UPDATED;
>
>
> With option 1 I can be sure NOT to get a BEGIN_REQ within the next
10ns
> because
> I did not provide an END_REQ.
> With option 2 I can get a BEGIN_REQ in the next 10 ns, because I
already
> gave the END_REQ
> (although it becomes "effective" only 10 ns in the future).
>
> So depending on that choice I can influence the timing of subsequent
> incoming BEGIN_REQs.
> The reason is that the rules are based on call order alone and not on
> their timing.
> IF you wanted to enforce that timings are the same for subsequent
> BEGIN_REQs in both cases (TLM_ACCEPTED or TLM_UPDATED)
> you would either have to say that the rules are based on timing, or
that
> you disallow timing annotations
> at AT.
> IF you base the rules on timing you enforce PEQs everywhere which is
> (from a sim speed PoV) equivalent to disallowing timing
> annotations.
>
> regards
> Robert
> >
> > Regards
> >
> > Yossi
> >
> > > -----Original Message-----
> >
> > > From: Robert Guenzel [mailto:robert.guenzel@greensocs.com]
> >
> > > Sent: Tuesday, January 04, 2011 3:07 PM
> >
> > > To: Veller, Yossi
> >
> > > Cc: systemc-p1666-technical@eda.org; tlmwg@lists.systemc.org
> >
> > > Subject: Re: [tlmwg] Revisit of the TLM2.0 phases rules
> >
> > >
> >
> > > IMHO the scenario you describe does not show that the rules are
broken.
> >
> > > It's the target that might be broken.
> >
> > > Or it's me who didn't fully understand the problem.
> >
> > >
> >
> > > I'll try to explain me view:
> >
> > >
> >
> > > T sends GP1(END_REQ) at t1+320ns. By doing that it indicates
> >
> > > that it wants to insert a delay between END_REQ and BEGIN_RESP
> >
> > > (otherwise it would directly do GP1(BEGIN_RESP) )
> >
> > >
> >
> > > The target knows what it did. Now it gets GP2(BEGIN_REQ).
> >
> > > If the target now returns UPDATED(BEGIN_RESP) it _knows_
> >
> > > that it now moves the RESP of GP1 _behind_ the RESP of GP2
> >
> > > (because it now assigns the RESP channel to GP2).
> >
> > > If it does not want to do that it can either return TLM_ACCEPTED
> >
> > > and finish GP1 first (by sending BEGIN_RESP), or return
> > TLM_UPDATED(END_REQ)
> >
> > > and finish GP1 afterwards as well.
> >
> > >
> >
> > > You say:
> >
> > > >
> >
> > > > The TLM2.0 base protocols rules created a scenario where two
> >
> > > > concurrent reads and writes of 320 NS took both 640 NS (this
should be
> >
> > > > impossible).
> >
> > > >
> >
> > > There is no BP rule that forces T to do what you describe.
> >
> > > And I do not think that it should be impossible. If the target
wants
> >
> > > to establish such a link between GP1 and GP2 it should be allowed
> >
> > > to do so. But it can decide to avoid/reduce the link like that:
> >
> > >
> >
> > > t= t1 I1 sends GP1(BEGIN_REQ) to B
> >
> > > B passes the GP1(BEGIN_REQ) to T
> >
> > > T computes that the written data takes 320 NS (because of rule
16.2.6 b)
> >
> > > and waits.
> >
> > > I2 sends GP2(BEGIN_REQ) to B, B queues it in a PEQ (because of the
> >
> > > BEGIN_REQ rule 16.2.6 e).
> >
> > > t= t1+320 NS T sends GP1(BEGIN_RESP) and B passes it to I1
> >
> > > I1 returns TLM_COMPLETED (seen both by B and T). GP1 is DONE.
> >
> > > Then B takes GP2(BEGIN_REQ) from the PEQ and calls T.
> >
> > > T returns TLM_UPDATED and changes the phase to BEG_RESP and B send
> >
> > > GP2(BEG_RESP) to I2.
> >
> > > I2 computes that the read data takes 320 NS (because of rule
16.2.6 c)
> >
> > > and waits.
> >
> > > t= t1+640 NS I2 sends GP2(END_RESP) and B passes it to T. GP2 is
DONE.
> >
> > >
> >
> > > Now at the target side both GP1 and GP2 last 320 ns. For I2 GP2
lasts
> >
> > > 640 ns but that is due to
> >
> > > the fact that GP1 and GP2 are scheduled by B.
> >
> > >
> >
> > > I agree that there is the problem of preemption and interleaving,
> >
> > > but the question is if that is something that AT abstracts away or
not?
> >
> > > I must confess that I am not sure about the answer to that
question.
> >
> > >
> >
> > > Due to the BEGIN_REQ rule preemption is not possible with another
> >
> > > BEGIN_REQ.
> >
> > > But how about ignorable phases TRY_PREEMPT?
> >
> > > After GP1(BEGIN_REQ) an initiator/interconnect can try a
preemption by
> >
> > > sending GP1(TRY_PREEMPT) and if it gets back TLM_COMPLETED
> >
> > > the preemption was successful if it gets back TLM_ACCEPTED the
target
> >
> > > is unable to preempt GP1. Should be BP compatible.
> >
> > >
> >
> > > For interleaving I'd say that is something that is abstracted away
at
> >
> > > the AT level.
> >
> > >
> >
> > > best regards
> >
> > > Robert
> >
> > >
> >
> > >
> >
> > > Veller, Yossi wrote:
> >
> > > >
> >
> > > > During the Review of the Draft LRM I revisited the TLM2.0 as the
new
> >
> > > > addition to the standard and found out the following:
> >
> > > >
> >
> > > > Let us look at two initiators I1 and I2 connected to a bus B and
> > target T.
> >
> > > >
> >
> > > > I1 writes to T a burst whose data transfer should take 320 NS
and
> >
> > > >
> >
> > > > I2 reads from T a burst whose data transfer should take 320 NS
at the
> >
> > > > same time (t1).
> >
> > > >
> >
> > > > Let us denote the generic payload (GP) from I1 GP1 and the GP
from
> > I2 GP2
> >
> > > >
> >
> > > > t= t1 I1 sends GP1(BEGIN_REQ) to B
> >
> > > >
> >
> > > > B passes the GP1(BEGIN_REQ) to T
> >
> > > >
> >
> > > > T computes that the written data takes 320 NS (because of rule
16.2.6
> >
> > > > b) and waits.
> >
> > > >
> >
> > > > I2 sends GP2(BEGIN_REQ) to B, B queues it in a PEQ (because of
the
> >
> > > > BEGIN_REQ rule 16.2.6 e).
> >
> > > >
> >
> > > > t= t1+320 NS T sends GP1(END_REQ) and B passes it to I1 then B
takes
> >
> > > > GP2(BEGIN_REQ) from the PEQ and calls T.
> >
> > > >
> >
> > > > T returns TLM_UPDATED and changes the phase to BEG_RESP and B
send
> >
> > > > GP2(BEG_RESP) to I2.
> >
> > > >
> >
> > > > I2 computes that the read data takes 320 NS (because of rule
16.2.6 c)
> >
> > > > and waits.
> >
> > > >
> >
> > > > T sends GP1(BEG_RESP) and B pushes it into the PEQ (because of
the
> >
> > > > BEGIN_RESP rule16.2.6 f).
> >
> > > >
> >
> > > > t= t1+640 NS I2 sends GP2(END_RESP) and B passes it to T (and
the
> >
> > > > write finishes)
> >
> > > >
> >
> > > > B sends the GP1(BEG_RESP) to I1 which replies with TLM_COMPLETED
> >
> > > >
> >
> > > > B sends the GP1(END_RESP) to T (and the read finishes)**
> >
> > > >
> >
> > > > The TLM2.0 base protocols rules created a scenario where two
> >
> > > > concurrent reads and writes of 320 NS took both 640 NS (this
should be
> >
> > > > impossible).
> >
> > > >
> >
> > > > Other scenarios show that relying on simulation order both read
and
> >
> > > > write can finish after 320 NS or that either one can finish
after 320
> >
> > > > NS and the other one after 640 NS. All the above happens because
there
> >
> > > > is an artificial linkage between the request stage of the read
and the
> >
> > > > data phase of the write (they use the same phases) and another
> >
> > > > artificial linkage between the acknowledge stage of the write
and the
> >
> > > > data phase of the read.
> >
> > > >
> >
> > > > IMHO these scenarios show that the rules are broken and have to
be
> > fixed.
> >
> > > >
> >
> > > > Moreover these rules don't support the following:
> >
> > > >
> >
> > > > 1. Preemption where a higher priority transaction can abort a
lower
> >
> > > > priority long burst of data in order to transmit its data and
let the
> >
> > > > aborted transaction continue.
> >
> > > >
> >
> > > > 2. Interleaving of the data of a slow burst with data of other
bursts.
> >
> > > >
> >
> > > > The fix cab be the following:
> >
> > > >
> >
> > > > 1. Specify that the BEGIN_REQ -> END_REQ stage is the address
passing
> >
> > > > stage.
> >
> > > >
> >
> > > > 2. Retain the BEGIN_REQ rule (16.2.6 e) that allows a target to
slow
> >
> > > > down upstream components.
> >
> > > >
> >
> > > > 3. Specify that the END_REQ -> BEGIN_RESP stage is the write
data
> >
> > > > passing stage.
> >
> > > >
> >
> > > > 4. Remove the BEGIN_RESP (rule16.2.6 f). An initiator should not
> >
> > > > anyways issue too many outstanding requests that it can't
handle.
> >
> > > >
> >
> > > > This fix will also support Preemption and Interleaving.
> >
> > > >
> >
> > > > Regards
> >
> > > >
> >
> > > > Yossi
> >
> > > >
> >

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