Re: IM's updated

Per, Shabtay,

Per I agree with Shabtay that your clarifications (original e-mail
entitled "IM's updated") were helpful and it would be good for Brian
to get these into the IMs.

Some minor additional clarifications I've embedded below
a couple of Shabtay's questions.

See johnS: prefix.

-- johnS


Shabtay Matalon wrote:
> 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.

johnS:
Yes. The idea is to maintain determinism, and therefore consistent
behavior regardless of optimizations put "under the hood".

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

johnS:
I think the main point here is that it does not matter who
sets the delay or what the delay is so long as there is a mechanism
to re-synchronize the times of the pipe producer and pipe consumer
if it becomes necessary to enter back into a mode of reactive
(alternating) interactions.  This is the purpose of the
flush call - to provide this re-synchronization.

For example, a pipe producer thread can be sitting there jamming
transactions into a pipe to its heart's content. The consumer
meanwhile is only consuming transactions which the producer
had written well into the past.

So in this scenario at any given point the consumer's time,
the producer is well into the future - how far into it,
we don't care.

Or, put differently, at any given point in the producer's time,
the consumer is well into the past. How far into it,
we don't care.

But suppose producer and consumer now want to interact reactively,
say with plain DPI function call interactions. They must synchronize.
i.e. the producer's present must become one and the same as
the consumer's present. To do this, producer issues a flush.
This guarantees that the producer thread blocks until all the
future transactions have dissipated to the consumer and now the
two are synchronized in time. At this point in time, the two have a
common present and are free to communicate reactively. And
all this can be done deterministically where interactions
take place on the same clocks on timed side regardless of
how much buffering an implementation provided or how much
concurrency it chose to use.

-- johnS
<eom>

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

-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________