RE: Streaming, batching, concurrent and alternating

Hi John,

> Per you have to be very careful when deciding what determinism to
> enforce here and where to draw the line.

Exactly my point.

> That is what we're talking about when we speak of determinism in
> the SCE-MI context. We need to insure that determinism is enforced
> on the H/W side. Allowing a solution where a transaction can come
> in on any non-deterministic clock cycle even if the HDL observes
> Cliff Cummings Guidelines is simply not acceptable.

SCE-MI 1.1 is such a solution.  You have to employ clock control
correctly, e.g., follow the `sane' clock control guidelines, in
order to ensure that transactions arrive deterministically.  However,
both SCE-MI 2.0 proposals do enforce determinism on the hardware side
the way you describe it, for the features that are 2.0 specific,
would you agree?  As far as I can tell the DPI function calls and
the transaction pipes in the Mentor proposal do this, and the
VLM input port in the Cadence proposal does this.

In your view, is the concept of determinism we need to be worried
about constrained to message arrival on the hardware side?  Actually,
I assume you also want message departure on the hardware side to be
deterministic in the same sense.  But what about message arrival on
the software side?  Would you consider Shabtay's batching of messages,
e.g., delayed arrival to still be deterministic?

> I would say both "defined right" and "implemented right". It is very
> easy to impose a requirement that the infrastructure prevents reactive
> calls in the middle of a stream.

How can you enforce this?  If the software side needs multiple
function calls to retrieve the message, what is to prevent it from
sending something in the middle of this message?  I suppose what
you can guarantee is that each chunk of the message is received
atomically.  Is this what you were thinking of?

> We strongly disagree with this. You can create random timing by using
> pseudo-random generated delays but still make it repeatable. 
> This way, if
> any failure is detected, it is repeatable with the same seed. This, in
> our view is an absolute requirement.
> 
> I would challenge you to describe to me a test scenario that 
> can only be
> accomplished with non-deterministic behavior that could not 
> just effectively
> be done with pseudo-random delays that are deterministic and therefore
> repeatable if bugs appear.

I think you misunderstood what I said.  I most certainly was not
describing a use model that relies on non-deterministic behavior to
do random testing.  I completely agree with you on creating random
timing using pseudo-random techniques.  I was responding to Russ'
statement that if there is a mechanism that introduces the *potential*
for non-deterministic behavior then the user might as well go to
the completely free-running use model.  I disagree with that precisely
because of the non-deterministic timing a free-running use model
implies.

So, Mentor does not support the free-running model except for what is
already possible in SCE-MI 1.1?

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