RE: Prioritization on SVCC's Charter, API issues

Subject: RE: Prioritization on SVCC's Charter, API issues
From: Ghassan Khoory (Ghassan.Khoory@synopsys.com)
Date: Mon Oct 07 2002 - 16:57:10 PDT

Bassam:
The web site is correct. The next meeting is on 10/15. We had back-to-back
meetings in the last two weeks to compensate for one that we missed during
the face-to-face meeting.
Thanks,
/gjk
  -----Original Message-----
  From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of Bassam
Tabbara
  Sent: Monday, October 07, 2002 7:31 PM
  To: Warmke, Doug
  Cc: 'sv-cc@server.eda.org'
  Subject: Re: Prioritization on SVCC's Charter, API issues

  Yeah Let's discuss. Although we'll definitely need to reframe your
questions, they remind me of how poll questions are posed as in a) do you
like this nasty thing, b) or this good thing :-)! Just kidding .... (and
don't ask me to propose an alternate, I'll know it when I see it :-)!).
  -Bassam.
  P.S. The web site says we are not meeting tomorrow ?? My calendar says we
are, who's right ?

  "Warmke, Doug" wrote:

    SVCC Team,

    **** Prioritization Issues ****

    I agree with Stuart Sutherland and John Stickley that it
    would be a good idea to prioritize our work to make sure
    we get something valuable done by our SV 3.1 deadline.

    In my discussions with users, I find that there is high
    demand to have a direct name-based binding between
    the C and HDL language domains (aka DFLI). I hear
    about this so often that I think this topic is the
    most important technical issue for the SV-CC committee
    to cover by the deadline.

    Note: I had composed this mail last Thursday but didn't
    send it yet. It looks like Michael R. agrees with
    this assessment.

    Also, my Mentor Emulation Division colleagues agree
    with this prioritizationy. Does anyone disagree?
    If so, let's get the emails out and then discuss
    in the meeting tomorrow.

    **** Thoughts on API for SV ****

    As several people have pointed out, it is difficult to
    write API's for language features that are still in flux.
    I understand what Kevin is trying to propose, but I can
    see the following problems with his suggestions:

        a) There is a large body of legacy PLI/VPI that must
           continue to be supported in SV. (anyone disagree?)
        b) Introducing the C/C++ elf/stabs-based debugging tool
           approach is an elegant concept, but if we introduced
           that and continued with PLI/VPI, the system would have
           redundant parts and thus be overly complex.
        c) I don't think that there is a large body of elf/stabs
           expert programmers in the EDA industry or the
           semiconductor industry which we serve. There are
           a few real experts, but not a large body.

    How will we put this issue to rest and decide
    "Yes we are going to put VPI into SV (and possibly extend it)"
    or
    "No we are rejecting all API access to SV and will enhance
    the language to do all the jobs that the old C code did"
    ?

    Let's discuss this at the meeting tomorrow.

    Thanks and regards,
    Doug Warmke
    Model Technology, Inc. 

--
Dr. Bassam Tabbara
Technical Manager, R&D

Novas Software, Inc.
bassam@novas.com
(408) 467-7893

This archive was generated by hypermail 2b28 : Mon Oct 07 2002 - 17:01:13 PDT