Re: Streaming, batching, concurrent and alternating

Per,

Bojsen, Per wrote:
> Hi John,
> 
>  > We cannot stress enough the importance of enforcing determinism
>  > in SCE-MI 2.0 for all use modes. Any solution which puts
>  > responsibility for determinism on the user or IP vendor level is
>  > unacceptable.
> 
> You are talking only about determinism on the hardware side, here,
> as per your previous email, right?  I like this to be stressed as
> I tend to view the whole system when I consider determinism, not
> just the hardware side.  But I think you're saying that if we can
> relieve the user from having to learn yet more guidelines (besides
> the Cummings ones) such as sane clock control, then we'll be better
> off.
> 
>  > We disagree with the premise that non-deterministic
>  > streaming is required for performance.
> 
> Doesn't it depend on what you mean by `performance'?  It is somewhat
> relative.  Are you saying that you disagree that non-deterministic
> streaming can yield higher performance than deterministic streaming
> in some scenarios? 

johnS:
Yes, I'm saying I disagree that non-deterministic
streaming can yield higher performance than deterministic streaming
in any scenarios


> Or are you saying that you disagree that
> non-deterministic streaming is required to get *adequate* performance?

johnS:
Yes, I'm saying I disagree that
non-deterministic streaming is required to get *adequate* performance.
I don't think it is required at all in fact and any SCE-MI 2.0
proposal should not allow it.

> 
>  > This is the ability to accumulate transactions on one
>  > end of a channel at a different rate than which they
>  > might be read at the other end (at least this is
>  > what I understood from Shabtay's e-mails).
>  >
>  > Although this was not part of the agreed upon goals,
>  > the Mentor proposal refers to this as "data shaping".
>  > A couple of scenarios were discussed in this thread.
> 
> I think there is an important difference between Shabtay's batching
> concept and data shaping as described in the Mentor model.  The
> difference has to do with the end-of-message handling.  I believe
> Shabtay's batching works on multiple messages, i.e., multiple
> end-of-message indications.  Doesn't data shaping only work on one
> message at a time?  At least that is how I interpret Section 4.4.2.2
> in your proposal where it says: `However, if /data shaping/ is
> involved, the infrastructure does not pass the eom flag until the
> last element of size bytes_per_element is read by the receiver'.
> Let me know if I misunderstood the handling of the eom flag.

johnS:
The Mentor pipes support both data shaping and eom.

You can use eom without data shaping, data shaping without eom,
or both together. We tried to design this flexibly, and based
on uses of it so far it seems to work in a fairly simple manner
to serve a variety of different needs.

We're open to ideas for even further improvement. As I've said,
this is a fairly compact facility that can be built over a
base DPI capability.

-- johnS
<eom>

> 
> Thanks,
> Per
> 
> --
> Per Bojsen                                Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
> 78 Dragon Ct.                             Tel:   781 721 8229
> Woburn, MA 01801                          Fax:   781 932 7488
> 

-- 

______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________