RE: Minutes from meeting

> Wouldn't ease of use requirements point us towards a specification
> where the user interface abstracts away how transactions are to be
> transported?

I certainly would hope so!  But this is not my point.  My point was
that we need to talk about what types of messages the interface
supports which is independent of the discussion about *how* it
transports those messages.  This is a separate discussion from
streaming versus non-streaming.

> I think SCEMI 2.0 should define a messaging mechanism that allows
> a message of any size to be transported "in zero time" (and that
> size to not be static, but variable from invocation to invocation);

Ok, now you're talking :-)  This I can agree with as a worthy goal
except I would not have put the VLM portion in a parenthesis.
Ideally, I would like to see an interface where I pass a pointer
to my transaction to an SCE-API function/method and have the data
appear on the hardware side with the implementation taking care of
all the nasty issues of segmentation/reassembly, byte ordering,
endianness issues, etc.

> and (possibly) another messaging mechanism that sets up a streaming
> operation.

This is where I think there are more things to consider.  I see
streaming as applying to at least three scenarios:

  1) Within a single message delivered in non-zero time;

  2) Across multiple messages;

  3) Within a message that is a true byte stream, i.e., it has no
     upper bound on its length.

Scenario 1 can be hidden entirely from the user.  The user need not be
aware that the implementation is streaming.  He just sends a long
message and the implementation allows the hardware side to start 
running when it has gotten a certain initial fraction of the message.
There are no determinism issues as the implementation guarantees
correctness.

In scenario 2, the user is aware of streaming going on.  Streaming
especially in the hardware to software side direction can now change
the behavior of the testbench if the user is not careful.  This is
also where using separate threads to service the streams can be
useful.

Finally, we discussed scenario three at the 3/9 meeting as yet
another possibility.  I do not know if this provides sufficient
value above the other scenarios to make it worthwhile considering.
It is, of course, similar to scenario 2 in how it might affect
the testbench and determinism/repeatability.  It seems to match
well to streaming media applications but could also be applied to
SONET-style applications where the frame stream is continuously
flowing.

> I'm guessing that you have in mind other types of messaging that
> can occur, which I might not (at present) consider necessary, or
> might consider to be implementable using the two fundamental
> messaging mechanisms I described above. If so, can you give an
> example?

VLMs delivered and/or consumed in non-zero time as described in
scenario 1 is one important example.  Messages that are
non-uniformly and partially consumed on the hardware side at 
different time points, each time in zero time is another one.

I will try to elaborate and expand on this later.

> I guess since we're talking about requirements and goals, "ease of
> use" has been established as a requirement, and "higher level of
> abstraction" MIGHT be acceptable as a goal. I don't know that ITC
> has attempted to establish a consensus on that.

Right, that's what was occurring to me.  I was implicitly connecting
the two like you was.

> We ought to talk about this. 

Certainly.

> True, but  higher performance can be achieved if streaming
> operations can continue to occur while the "main" sw execution
> is blocked and hw is running. 

Right, agreed.  But I am pretty sure we can relegate this to the
application level.  What we should do is to make sure the interface
is defined such that this remains possible (it is today).

> It might help in a purely organizational sense, even if it's the
> same people. 

Yes, that is a good point.  And like Matt was indicating, perhaps
it will be easier to attract other people if it is separate from
ITC.

> A measure of the usefulness of the implicit state machine style is
> that I doubt anyone here who wrote these behavioral verilog tools
> knew or cared about implicit state machine design, but these tools
> by and large conform pretty well to the implicit state machine style.

So you're really not looking for new technology, but `merely' an
effort to standardize the tools that already exists?

> [...] moving towards defining a superset of strict RTL [...]

One observation that could help constraining this is that the
behavioral synthesis of transactors does not necessarily have to
be as optimal as the for the DUT (if it was coded using a behavioral
style).  This will make the implementation a lot easier, I would
think.

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