RE: Minutes from meeting

Hi Russ,

>     I think the discussion of this whole topic of VLMs, FLMs, 
> streaming, zero-time, etc., has gotten overly complicated.

Yes, we are trying to bite off a big mouthful here.

> I believe the whole spectrum of issues here, when approached
> with the conviction that SCEMI 2.0 will sufficiently raise the
> level of abstraction for the user, boils down to streaming vs.
> non-streaming (or as Shabtay has put it, concurrent vs.
> alternating -- probably a more descriptive syntax).

I think this is an oversimplification even in the context of
a higher level of abstraction [1].  The distinction of streaming
versus non-streaming or concurrent versus alternating says nothing
about how my transactions are to be transported.  For example, you
could come up with a definition that supported streaming and
non-streaming modes, yet only allowed fixed width/length messages
to be transported.  We really do need to explicitly talk about
the type of messaging that can occur.

[1] BTW, I looked over Duaine's slides again and could not find
anywhere where it is explcitly stated that we should move to a
higher level of abstraction.  Sure there is some mention of
various modeling constructs, etc., but it is not stated that
we are aiming for a higher level of abstraction.  Do we need to
add this?

> At a higher level of abstraction, non-streaming issues ought
> to become trivial  -- there should be one user interface for
> messages of any size, and let the vendors decide
> how to get it from point A to point B.

I agree with this, but we really need to define what this interface
allows, i.e., only fixed width messages, messages with variable
length but with some upper bound, VLM with no upper bound, etc.
These details really do affect what the interface ends up looking
like.

> Streaming is a more difficult problem and involves threading
> (and how to do it),

I believe threading can be left to the application layer.  We
need to define streaming such that this is the case.  This will
allow SCE-MI to interoperate with any threaded and non-threaded
environment.  Note, you do not need threading to support
streaming.

> Why not spawn off the modeling task into a separate, parallel 
> committee closely aligned and coordinated with the ITC
> interface activity?

I am worried that the only people interested in such activity are
the people on the ITC committee so this would not really help.
If this was broadened to some sort of behavioral synthesis subset
standardization effort, perhaps more people would be involved,
but as Brian pointed out in one recent meeting the behavioral
subset we are interested in is not necessarily the same subset
other people are interested in.  This whole thing seems like a
huge effort anyway.  For one, it sounds like we need to lean on
some behavioral synthesis experts lest we define some subset that
turns out to be unimplementable or very difficult to implement
in a synthesis tool.  Given that efforts to standardize the
simpler RTL-level synthesizable subset did not succeed in the
past, what are the chances that a similar effort for a behavioral
subset would succeed?  Not a reason not to try of course, but
perhaps the scope needs to be narrowed and then we are back to
doing it within the scope of ITC . . .

I'm assuming that Broadcom has some specific behavioral modeling
styles they'd like to see supported in emulation?

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