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

Hi Jakob,

Comments embedded.

Regards
Yossi

> -----Original Message-----
> From: Engblom, Jakob [mailto:Jakob.Engblom@windriver.com]
> Sent: Wednesday, January 05, 2011 2:46 PM
> To: Veller, Yossi; Robert Guenzel; tlmwg@lists.systemc.org
> Cc: systemc-p1666-technical@eda.org
> Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules
>
> > 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.
>
> Unrelated to this discussion in detail, the general concept of such
time
> volatility is well-documented in other fields. If you have a shared
resource,
> and change the order of access, you cannot really expect any
"reasonable
> bound" on the outcome. In real-time systems and worst-case execution
time
> analysis it is known as a timing anomaly, and there are nice examples
showing
> how they can snowball arbitrarily due just to a small change in the
order of
> events. "Arbitrary" is really only meaningful if you have explicitly
designed
> the system such that the change is without significance.
>
> To me, the timing effects seem to be a property of the model and, by
> extension, the hardware being modeled. If the hardware is immune to
these
> effects, I guess the model also has to model the mechanisms behind
this.

My point is that the time volatility is artifact of the TLM2.0 rules and
not of the application itself.
Do you agree with me that, if my claim is true, this is a problem in the
rules?

>
> And to me, this seems like a bad model of the behavior:
>
> > T computes that the written data takes 310 NS (because of rule
16.2.6
> > b) and waits.
>
> Doing a wait() here effectively says that T is busy until the wait is
done -
> and that does not seem to be true for your target, as it will really
be able
> to respond to transactions while it "write component" churns away in
the
> background. Hard to say that the BP is broken, right?
>
> Would seem more appropriate for T to return immediately, and use an
event
> posted to the future to later send back the reply right? And then when
the
> next request comes by, it is free to receive another call?

Yes. I should have written here that it schedules an event to be
awakened after 310 NS. What you've said is what I intended.

>
> /jakob
>

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