RE: Streaming, batching, concurrent and alternating

 Just a couple comments in blue
 
[Shabtay] 
 >Do you both agree that using "concurrent" as the reciprocal to alternating
is a better name? 
No. I prefer talking about deterministic vs. non-deterministic. Alternating
is by definition 
deterministic, but "concurrent" can be either. If "streaming" is implemented
right, some concurrency 
can be achieved and it will still be deterministic. 
Determinism is the key distinction. Also, we agreed for SCEMI 2.0 that
determinism would be the default (unlike SCEMI 1.1 where the user must take
care to design the appropriate clock control to get it).
[Shabtay] I agree that determinism should be the default. Alternating mode
is also deterministic by definition as you stated and thus I proposed that
it should be the default. I think we should have further discussion on
"streaming being implemented right" when we drill into more detailed
discussion at the committee. You indicated for example that you need a
threading package to make it deterministic and we avoided so far building an
interface that assumes the use of threads. I hope that you can make some
suggestions how streaming could be supported such that that it will be
deterministic.

It's a big topic. Perhaps Mentor would like to take a crack at it. I've
discussed streaming with John, and while I haven't fully thought through the
"transaction pipes" scheme  -- and defer endorsing it until I do  -- I think
John and I see the streaming issue conceptually the same.

 
[Shabtay 
 >Correct. Assume that a cycle stamp defines the time a message is
delivered. Or even assume that the message embodies various cycle stamp
values read explicitly by means that the infrastructure provides. The end
user may determine the level of batching required by its testbench
environment for output messages on a given interface (same may apply on the
producing side). The messages will arrive on each channel in order, but
multiple output messages will arrive at the same time, each message with
continuously increasing cycle stamp values. In SCE-MI 1.1 this is not
allowed.
You can get into serious trouble batching output messages from different
times (cycle stamps) for delivery. Suppose output message A is produced at
cycle stamp N and is batched with output message B at cycle stamp N+1000. If
follows that the "batched" output message isn't sent over to sw until at
least N +1000 (causality). Now, suppose sw has an algorithm where when it
receives an output message A, it needs to send an input message to some
other port 500 cycle stamps later. What is sw to do? This system will either
be non-deterministic or will be deterministic in an absurd way (where
batching introduces delays that aren't present in the real environment).
Output messages must get to sw in zero time after they were produced. SCEMI
1.1 is correct not to allow this kind of batching but doesn't go far enough
by requiring that hw stop its own clock when output messages are pending.
[Shabtay] The scenario that you described illustrates the importance of
"reactivity control" that I described in the paper. In the scenario that you
have presented, the end user should not modify the default setting of the
channel as using a reactive test on a "batched" channel can yield a dead
lock. On the other hand, it's quite possible that the software side monitors
certain interfaces independently wrt others. Under this scenario, delayed
arrival is acceptable to the test as Per pointed out.
I already agreed with you that the determinism should be the default. But I
don't think that it will satisfy end user performance goals if SCE-MI will
be unnecessarily constrained. Many testbenches are either not fully reactive
and some are even non-reactive at all.  I thus think that it is important
that we provide the "knobs" to users to obtain higher level of performance
knowing the characteristics of their specific test environment. While we do
that, we should also make sure that modelers who create transactors for both
simulation and acceleration mode are not negatively impacted due to these
performance optimizations. Batching allows for performance optimization and
yet doesn't impede on the portability of transactors from simulation to
acceleration and from once accelerated environment to another.
Let me know if you disagree with this.

If a user uses those knobs and introduces the slightest indeterminism, he
might as well just put the system in free running mode and forget about
knobs. Wouldn't this be easier for a not fully reactive testbench? I'd like
to see a knob that puts an interface into a careful streaming mode that
guarantees determinism.

Is a "free running mode" knob something we've overlooked? I've just assumed
the ability to turn off clock control (or the SCEMI 2.0 equivalent of it)
but all we've discussed is the knob to turn on/off streaming for a
particular interface suibable for streaming. I would support this 2nd
"knob", but I would contend it would negate the need for any others. Maybe
it could be an argument to scemi->Init();
 
 
  
  
> 
>Per 
> 
>