RE: ITC Meeting Minutes for May 26th

Hi Shabtay and Russ,

> We use some terms differently which may cause some confusion. For
> example, you use the term “streaming vs. purely alternating” below by
> defining streaming mode as what I call concurrent.

`Streaming' is normally taken to mean that each end of the conduit
run concurrently.  A good example is streaming video.  The server is
sending video data concurrently with the viewer showing the video.
So, with the standard definition of `streaming', concurrency is
implied and inseparable.

> I simply contrast concurrent vs. alternating indicating whether the HW
> side and the SW side take turns or run at the same time (aka
> concurrently). I separate this use model from “streaming” meaning
> delivery of multiple transactions in a batch by my definition.

In contrast to streaming, batch delivery of messages can occur even
if both sides are not running concurrently.  In SCE-MI 1.1, for
instance, it is possible for an implementation to allow multiple
input messages to a given port to be transferred to the hardware side
in a batch.  However, this is not really possible on the output
side as it would violate the ordering requirements.  That is, it is
not possible for output messages with different cycle stamps.  Messages
that arrive at the same port during the same cycle stamp, i.e., when
the controlled clocks are stopped, could be batched.

So I'm thinking Shabtay is referring to possibly allowing a use model
where output messages can be batched even if they arrive at different
cycle stamps.  This is similar to streaming but not quite the same as
batching can occur without concurrency.  It would then merely be a
way to optimize the use of the physical channel between the hardware
and software sides.

Per