RE: Streaming, batching, concurrent and alternating

Per, John, my comment at the bottom.

> Per,
> 
> Comments embedded ...
> 
> Bojsen, Per wrote:
> > Hi Russ,
> > 
> >  > No. I prefer talking about deterministic vs. non-deterministic. 
> > Alternating  > is by definition deterministic, but 
> "concurrent" can be 
> > either.
> > 
> > I'd like to point out that alternating execution does not guarantee 
> > determinism.  One example in SCE-MI 1.1 terms is when two output 
> > messages arrive at the same uclock.  In that case, the 
> behavior of the 
> > test could depend on the order in which the output message 
> callbacks 
> > are executed. This order is not defined by the standard.  You would 
> > have the same potential problem in the DPI world when two imported 
> > functions are called at the same simulation time.  Verilog 
> semantics 
> > does not specify the order in which these
> > two functions will be called.  So, even in alternating mode 
> there is a
> > burden
> > on the user to ensure the deterministic behavior of his 
> test.  I'd like to
> > be able to state it is easy to do, but I've seen too many 
> examples of people
> > managing to create non-deterministic behavior in this case.
> 
> johnS:
> Per you have to be very careful when deciding what 
> determinism to enforce here and where to draw the line.
> 
> True, Verilog naturally has race conditions. This has been a 
> problem for years. Two different simulators (or even the same 
> simulator with two different compiles) will give different 
> results if there is code that is written in such a way as to 
> depend on races.
> 
> However, at the same time, there are very clear guidelines 
> (what we call "Cliff Cummings Guidelines") to avoid this 
> scenario in synchronous RTL style designs. People know how to 
> do this and it works.
> 
> 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.
> 

Per touches on a distinction between HW-side determinism and the less
discussed problems of SW-side determinism.

In the example where two MsgOuts happen on the same uclock, it is true
that this is analogous to a "same delta-cycle race" in pure verilog
simulation.
This can be hazardous, but might still be deterministic as long as the
particular 
simluator and the particular compilation snapshot ( in simulation ) and as
long
as the implementation ( in SCEMI ) keep the ordering of execution the same.

If one can't (and one shouldn't) depend on the ordering, the problem is
fixed in sw if it is written
so that processing derived from one callback doesn't depend on results of
another callback if the
callbacks occur on the same cycle stamp. I.e., callbacks should only fetch
and put data
in a time-ordered queue, and the higher level algorithm should process in a
time-aware manner.

There is a difficult case which I'll describe as follows:
  * transactor A generates MsgOut A on Cycle Stamp N
  * transactor B generates MsgOut B on Cycle Stamp N
  * callback(A) is processed first (by arbitrary choice of implementation
logic)
  * return is passed to the main C algorithm which, due to callback(A) needs
to send a 
    MsgIn to transactor A immediately (Cycle Stamp N+1 too late)
  * callback(B) is processed. The information contained explicity tells the
main C
    algorithm not to send any MsgIns to transactor A.

The only foolproof easy way to accomplish the above is to design transactor
A to have a MsgIn
port that can handle a command to <cancel> the previous MsgIn received.

An ugly way to accomplish the above would be for C to immediately send a
"caboose" transaction
back to HW ( after seeing the callback(A) results ). The HW transactor
handling the caboose 
transaction would immediately send a MsgOut back to C. Two things must
happen for this to work:
a) this is all occurring while cclocks are stopped, and b) we must assume
that the callback for
the caboose transaction will occur after callback(B) -- I'm not sure what
the spec says about this
but it's reasonable for an implementation to work this way because
MsgOut(caboose) will be several
uclocks after MsgOut(B). Given all that, it would be up to callback(caboose)
to arbitrate the 
information from callback(A) and callback(B) -- which in this case would
mean it would not send the
MsgIn at all.


The larger general issue of determinism in SW is a can of worms that
can be a problem even if HW determinism is taken care of properly. To
further illustrate the
point that all things can be done right on the HW side, but still not be
deterministic
due to bad SW design consider the ad absurdum case where SW simply calls the
system("date") function
in its algorithm and uses the result to calculate when to send the next
packet after 
receiving a "packet done" callback from HW. HW could be obeying all the
right rules for
determinism and this system will be randomized via SW control.

This dicussion is an indirect answer to Per's point that alternating 
execution does not guarantee determinism. Obviously an attempt at
categorizing these
cases and coming up with brief formulas is a little more complicated than
first meets the eye.

This is another reason I favor discussing the whole subject
in terms of "deterministic vs. non-deterministic" because those qualities
are what is
ultimately important.