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.

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?

/jakob

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