RE: IM's updated

Hi Per,

Thanks for your clarifications. I hope Brian will append these
clarifications to the IMs and that someone from Mentor will alert us if
any of the clarifications that you are making is incorrect.

I have injected few comments where applicable and asked few questions
that could be added to the IM notes.

Thanks,

Shabtay

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen
>Sent: Wednesday, September 28, 2005 8:06 PM
>To: itc@eda.org
>Subject: 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.
[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. We should aim for an API that
is common on both and runs as native in simulation as it runs with
emulation. 
>
>> 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.
[Shabtay] OK. I agree with this.
>
>> 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?
[Shabtay] 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.
>
>> 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).
[Shabtay] 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. 

Pipes are set to enable delayed arrival. Correct? Who sets this delay?
The transactor model or the end user (who may be the recipient of a
block box transactor)? Have we touched on this question yet? 
>
>> 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
>
>