RE: IM's updated

Hi Shabtay,

> IM 207 - Have we agreed on the term "emulation of the emulator"?

This was a term Brian used to describe the difference between pure
simulation of a design and simulating an emulator running (emulating)
the same design.  There is no need to agree on this term as it does
not apply to SCE-MI 2.0.  Any vendor is free to implement something
like this and it will appear to the user as simply another target.

> I don't see a need to draw a distinction between simulators and
> emulators (besides performance).

>From a spec point of view, no.  This distinction matters to the user
from other points of view such as ease of debugging, visibility,
compile time, etc.

> IM208 - "For streaming, only supported by models that are pure sources
> or pure syncs. Any concurrency can be added to an alternating system so
> long as it does not alter behavior. In these cases an alternating
> behavior is the benchmark. These are all viewed as implementation
> optimizations and should not be specified or mentioned in the
> specification."
> 
> We need to evaluate if concurrency does not introduce lack of compliance
> among various simulation and emulation environments. I don't see how the
> rate that messages are sourced or synced could be the same when
> concurrency is used. Does it?

Note that the text said that concurrency could be introduced by the
implementation as long as it does not alter behavior.  So we've
established and all agreed upon that the new DPI/function based subset
of SCE-MI 2.0 is a system that uses alternating execution.  This
follows directly from the DPI definition.  However, this applies
only to the behavior of the system, not necessarily to what is actually
going on under the hood.  There are plenty of opportunities to
optimize the transport and execution that does not change the behavior.
This includes introducing some degree of concurrent operation.  Do
you agree that it does not matter that there is some degree of
concurrent operation as long as it behaves exactly like a purely
alternating system would?  SCE-MI 2.0 will describe the semantics
of the DPI/function based interface in terms of alternating execution.
The implementation is compliant as long as it preserves this semantics.
It does not matter one bit how the implementation achieves this
under the hood, agreed?

> IM209 - We had some discussion about setting buffer depth for pipes. It
> was my understanding that Mentor proposes setting the buffer depth by
> the infrastructure and not by the user. Is this correct?

This is my understanding as well.  If the system is deterministic and
observes alternating semantics, then I do not see any need for a user
setting of buffer depth.  This is because the buffer depth setting
would have no observable impact on the behavior of the system.  There
are other problems with a user settable buffer depth: it is unlikely
that a given buffer depth setting would achieve optimum performance
in all implementations.  Note, I am saying that I do not think a user
setting for buffer depth should be in the SCE-MI 2.0 standard.  However,
any implementation is free to provide its own performance optimization
knobs outside of the standard which could include buffer depth setting.
I do not see such features as leading to a non-compliant implementation
(necessarily).

> How would user obtain matching results if each implementation sets its
> own buffer depth?

By the simple fact that the pipes are deterministic.

> "Pipes can be layered over an alternating mechanism to obtain data on a
> continuous basis". I was under the impression that pipes are intended to
> be used for streaming channels. Is this the not the case? Can someone
> clarify if pipes are used for any type of channel (streaming or
> reactive) of just streaming and on which basis the user will choose
> using pipes vs. using DPI directly?

It is my understanding that pipes are intended for streaming, batching,
variable length messages, and potentially can be used even for more
exotic purposes if the modeling subset allows it.  Given that pipes
can be implemented at the application layer, the choice between using
pipes and DPI is one of convenience in many cases.  However, since an
implementation can choose to provide an optimized version of the pipes,
this would be a factor as well in the choice to use them.

> IM210 - "Determinism is guaranteed in an alternating environment." Does
> it mean that SCE-MI 2.0 promotes two modes, one that is deterministic
> and one that is not? 

No, it only provides a deterministic mode.

> IM211 - "This is a modeling subset issue." I don't understand this
> summary. Can one explain how it responds to the issue?

Many of the issues in IM211 were covered in the discussion on IM209.
Brian's summary dealt with the portion of IM211 not covered, which
was the issue of zero versus non-zero time delivery of chunks of the
messages sent over the pipes.  This turns out to be a modeling subset
issue more than a transport layer issue.

Per