Minutes of BTF Meeting July 14, 2003

From: Steven Sharp (sharp@cadence.com)
Date: Mon Jul 14 2003 - 12:58:51 PDT

  • Next message: Kurt Baty: "operator overloading"

    Precedence: bulk

    Minutes of BTF Meeting July 14, 2003

    Meeting started at 10:40 Pacific Time.

    In attendance:
            Kurt Baty
            Jay Lawrence
            Steven Sharp
            Karen Pieper
            Brad Pierce
            Gord Vreugdenhil
            Scott Cranston
            Francoise Martinolle
            Stuart Sutherland
            Tom Fitzpatrick

    Passed minutes from June 16, 2003

    SNUG technical phone call this week to discuss technical forum. Some
    logistical issues to be handled.

    ICU status evening of first day 5-6:30, unofficial session to allow
    outsiders entry.

    Jay proposed questionaire and incorporated feedback from Kurt. Still
    need more feedback from Fitz.

    Scott will look at the enhancement requests that I added from Verilog-AMS
    and flesh them out.

    Kurt suggested that the math functions from AMS be implemented as some
    kind of Verilog packages. Almost all of the AMS routines are already
    covered in Kurt's variable width floating point libraries. However, if
    the types are not built-in, then they could not be used with infix
    operators without something like operator overloading. Gord pointed out
    that there would be serious problems integrating operator or function
    overloading with Verilog's type system.

    There was further discussion of whether it was feasible to integrate
    Verilog-AMS and IEEE 1364 under some "umbrella standard". Some examples
    were given of where Verilog-AMS did something differently than IEEE 1364
    might want to do it (wreal vs. wire real, "built in math functions" vs.
    system functions or standard packages). Some of these may be due to
    IEEE 1364 doing a broader extension calling for a more general mechanism.
    Others might be due to AMS inheriting from Verilog-A, where backward
    compatibility with Verilog was not an issue. Many of the features may
    have been designed to meet particular analog needs, which may have made
    them less suitable for digital usage. Dynamic parameters were discussed
    as an example of something very important to analog simulation that might
    not be relevant to digital simulation. The AMS features proposed as IEEE
    enhancements so far are probably just the best-fitting ones.

    During discussion, it was determined that different people had different
    ideas of what it would mean to have an "umbrella" or "superset" language
    that included Verilog and Verilog-AMS. Getting full compatibility might
    require compromises from the Verilog-AMS standardization group, which is
    not formally coordinated with IEEE 1364 and might not be willing to make
    modifications. Any features added in the next 1364 standard could take
    overlap with AMS features into account, but it is not clear what mechanism
    could be used now to help with overlap in further 1364 standards. It was
    pointed out that any "language compatibility" options that were applied
    when compiling modules would not cover language incompatibilities in
    handling interconnection between modules. AMS is a particular issue,
    since it creates implicit things in interconnect, e.g. connect modules.

    Any questions on a 1364/AMS superset language in the user input
    questionaire may need to be clarified to avoid different interpretations
    of what that means.

    This archive was generated by hypermail 2.1.4 : Mon Jul 14 2003 - 13:02:44 PDT and
    sponsored by Boyd Technology, Inc.