RE: Minutes from meeting

First, let me apologize for being largely AWOL the last couple weeks. It's
amazing how the mundane, weary activities of actually producing ICs and
other money making activities can detract from doing the cool stuff :)


Regarding the several emails sent the last few days from Shabtay, Per,
Duaine, et. al., I have a few comments:

1) VLMs, streaming, concurrent vs. alternating, etc.

    I think the discussion of this whole topic of VLMs, FLMs, streaming,
zero-time, etc., has gotten overly complicated. 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). 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. Streaming is a more difficult problem
and involves threading (and how to do it), lack of concurrency in the
software only mode... a number of issues. I will make some more detailed
comments about this in another email.

2) "Transaction logging".

    Count me/BRCM in the camp that views this as "nice to have", potentially
a discriminating feature for deciding among competing SCEMI compliant tools.
I don't think the standard should get bogged down in addressing this.

3) Modeling as part of the ITC charter

    If you look at the priorities for SCEMI 2.0, and put getting IP vendors
to use the standard for their products, then modeling suddenly has a
significance higher than some (such as I) originally would have given it. My
experience where I work is that stricly RTL transactors are an order of
magnitude more difficult to produce and debug than more flexible behavioral
transactors. That said, ITC shouldn't bite off more than it can chew in its
task of getting a SCEMI 2.0 spec out before the end of the year. Why not
spawn off the modeling task into a separate, parallel committee closely
aligned and coordinated with the ITC interface activity?

    While on this topic, I tentatively suggest looking at the VHDL VITAL
spec's use of "Level0" and "Level1" as attributes on the architecture of
VITAL models. Level0 meant it was standard VHDL; Level1 meant it conformed
to certain restrictions that allowed simulator vendors to accelerate the
model. Perhaps something like this might work for transactor modeling.
Level0 could be standard synthesizeable RTL, and other levels could be
developed to allow flexibility in model writing. An IP vendor could
advertise that it supplies a "SCEMI 2.0 Level x model". Just a thought.

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



-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Brian Bailey
Sent: Thursday, March 24, 2005 10:59 AM
To: itc@eda.org
Subject: Minutes from meeting


        Please find attached the minutes from today's meeting. Important
action item for everyone - all proposed modification, or acceptance of the
goals must be mailed to me by 3/30
        
        Thanks
        Brian