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

> > 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?

Is the core problem really that we have a rule that makes certain operations "lock" the bus (or rather, function call interface into a certain model) for an amount of time that you do not think you have on hardware?

Isn't Robert's reply right on spot:

> You claim the rules are broken, but they are not. They just do not fit
> your expectation of
> fully independent read and write channels within a single socket.

Right?

Any API will have its space of "easy" modeling tasks, and its space of "hard" modeling tasks. Fully independent channels are not the target for the TLM-2.0 AT BP, can we agree on that? There are other APIs that cannot model pipelined accesses, such as the TLM-2.0 LT BP, and that is an acceptable limitation.

/jakob

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