RE: IM's updated

Hi Shabtay,

> We of course distinguish between a simulator and emulator, but
> I am concerned if we distinguish between simulating a design and
> simulating an emulator running the design.

Right.  From the point of view of the SCE-MI spec we do not
make this distinction.

> We should aim for an API that
> is common on both and runs as native in simulation as it runs with
> emulation.

Agreed.  We should aim for a standard that allows the user to view
simulation and emulation as interchangeable.

> What is done under the hood is left to the implementers. What
> I care about is maintaining determinism when using all engines including
> simulation. Let's simply table that.

Ok, good to see we are all on the same page on this issue.

> User should not care about any buffering that it set by the
> implementation as long as message arrival ordering on various channels
> is not impacted by the setting of implementation buffer depth. 

Correct.

> Pipes are set to enable delayed arrival. Correct? Who sets this delay?

The implementation does.  Actually, it depends on what you are asking.
The arrival of messages could be seen as determined by the consumer
based on when they are asking for data.

> The transactor model or the end user (who may be the recipient of a
> block box transactor)? Have we touched on this question yet?

Only vaguely.  But the general idea is that any delays introduced
will not change the behavior.  The mechanics of arrival of data is
hidden from the user.

Per