RE: Minutes from meeting

> -----Original Message-----
> From: Bojsen, Per [mailto:bojsen@zaiqtech.com] 
> Sent: Friday, April 01, 2005 8:33 AM
> To: 'vreeland@broadcom.com'; brian_bailey@acm.org; itc@eda.org
> Subject: 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.

Wouldn't ease of use requirements point us towards a specification where the
user interface abstracts away how transactions are to be transported? 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); and (possibly) another
messaging mechanism that sets up a streaming operation.

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?

> 
> [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?

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.

So, "higher level of abstraction" is a product of my a priori thinking --
that is I view it as highly correlated with "ease of use".

We ought to talk about 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.

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.

> 
> > 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.

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

 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?

Our verification teams have used transaction based testbenches in a purely
verilog environment as far back as 1998. We have probably 10x more
behavioral verilog transactors than RTL (emulation-specific) transactors.
One reason for that is they are perhaps 10x easier to write. 

There is a behavioral style called implicit state machine design which is
certainly a lot more liberal and flexible than strict RTL, but which doesn't
by any means open the floodgates to the intractable problems in synthesizing
a much larger subset of an HDL. 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.

The problem of IP vendors tackling (what are) separate little chip designs
in designing RTL transactors, which are not useful for anything else than hw
acceleration or emulation, is real, and moving towards defining a superset
of strict RTL that eases that pain will go a long way towards enabling the
IP vendors to support SCEMI type modeling.

> 
> 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
> 
> 



---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------