Re: Streaming, batching, concurrent and alternating

ITC,

The discussion on this thread has been a good one.
Shabtay and Russ have brought out some good
clarifications of some items in the Cadence
terminology that I think were needed. Here I attempt
to clarify similar items in the Mentor terminology
as well.

Bear in mind that most of these things are issues
can be resolved in further detail once either of
the proposals is selected.

The only possible exception to this that we see
so far is determinism in streaming. Mentor believes
that an absolute requirement in any use model,
whether streaming or reactive, is determinism.
We're still struggling to see how this is achieved
with the SceMiMessageVarPorts.

Determinism was clearly one of the SCE-MI 2.0 goals.

----------------------------------
Determinism

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.

Imagine any bug that occurs 3 hours into a
non-repeatable (i.e. "free-run") simulation.

We disagree with the premise that non-deterministic
streaming is required for performance. Our experience
has shown us otherwise. This is why the Mentor transaction pipes
were designed to allow the infrastructure to insure
determinism on the H/W side.

----------------------------------
Concurrent vs. alternating execution

We've been using the term streaming vs. reactive to discuss
more or less the same concepts.

Our "reactive" model essentially implies alternating
execution between host and emulator. The basic
DPI function call interface as described in the
SystemVerilog LRM offers this basic reactive capability as is.

Our "streaming" model defines a pipe (which can be
easily implemented in C over the base DPI capability)
by which transactions can be streamed between one side and
the other.

Two dynamics are at play in the streaming model:

1. The implementation can chose to (but is not
    required to) perform an optimization to allow
    the producing thread (or process) of a pipe to execute
    concurrently with the consuming thread (or process).
    This allows for concurrent transaction pre-fetch say in
    a stream of data going to H/W, or for
    concurrent transaction post processing say in a
    stream of data coming from H/W.

2. The implementation can chose to do some type
    of internal buffering or some type of double
    buffering scheme in a stream to only transfer data across
    the link at optimal points. Originally this is what
    we thought Cadence meant by batching but Shabtay
    made it clear (I think) that "batching" is at the user level
    not the implementation level - so in that sense it
    fits more with "data shaping" described below.

    Nonetheless, implementations can chose to (but are not
    required to) perform some kind of buffering
    for stream optimization much as Unix streams do.

Also, our "flush" mechanism in pipes allows for
switching a thread between streaming and reactive
mode. In one of Shabtay's responses he suggested
that such a capability is useful. Indeed we've found
it to be as well.

A flush is a confirmation that a transaction has been
propagated via a pipe and consumed at the other end.

Flushes offer reactive sync points for things such as
interactions between video streams that Per was talking
about.  This allows threads to switch between streaming
and reactive modes (i.e. between alternating and concurrent).

Additionally our "end-of-message" marking capability
addresses what I believe to be a consensus on
the meaning of "variable length messaging". From
Shabtay's responses, Cadence's interpretation of "VLM"
appears similar.

--------------------------------
Batching

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.

For example, sending a batch of transactions
from C to HDL all at once but reading them "one at a time"
from the other end.

This is our "funnel" concept in data shaping as
described in the Mentor proposal.

Another example was accumulating a series of
transactions even over a number of clocks on the HDL
side and sending them all at once to the C side.

This is our "nozzle" concept in data shaping
as described in the Mentor proposal.

It is important to recognize that "data shaping" works
symmetrically for both the input and output directions.

-- johnS

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