5/13 Datatypes Meeting Minutes

From: Kathy McKinley (mckinley@cadence.com)
Date: Fri May 14 2004 - 14:56:13 PDT

  • Next message: Stefen Boyd: "Re: 5/13 Datatypes Meeting Minutes"

    Attendees:

            Kurt Baty
            Shalom Bresticker
            Tom Fitzpatrick
            Atsushi Kasuya
            Michael McNamara
            Kathy McKinley
            Dave Rich
            Stu Sutherland

    Action Items:

            - Kathy to ask for the following items on the next BTF agenda:
              enhancement 287, and bit/logic datatypes
            - Kathy to send some wording on bit and logic to the datatypes group
            - Dave to send some words or examples on a possible "var" keyword
            
    Summary:

    Minutes from last meeting approved.

    We agreed to remove enhancement request 384 (mfactor) from the list
    of issues that the datatypes group will consider. This issue is
    fundamentally analog (voltage, power, and noise are involved
    in the scaling algorithm). With that removed, the current list is

         55, 61, 62, 357, 384, 385, 391

    We can use email to add other items that we want to consider.

    The contention around names for 2-state and 4-state datatypes is based
    on concerns about keyword conflicts in existing Verilog designs.
    Enhancement request 287 (`compatibility) discusses a directive
    that could help a designer work around such problems. The datatypes
    group strongly recommends that some mechanism like this be discussed
    and approved at the BTF level. We will ask for 287 to be put on the BTF
    agenda with high priority.

    We unanimously endorse the keywords "bit" and "logic" for primitive
    2-state and 4-state datatypes, respectively. These keywords denote
    datatypes, not object kinds. These names should be keywords because
    they are too fundamental to be redefined by the user. These names have
    the following advantages:

        - These names are natural to hardware designers

        - These names are compatible with SystemVerilog

        - These names are compatible in form and meaning with
          the analagous SystemC types sc_bit and sc_logic

    We spent some time discussing what it means to connect a 2-state net
    to a 4-state net. This is a fundamental issue that needs to be resolved;
    however, there is much to be considered. What do users want to see?
    How does this affect port collapsing rules? How is performance and
    optimization affected? We will continue to work on this issue.

    We resumed discussion of meanings of existing Verilog keywords,
    trying to classify them as "datatype" or "object kind". We may
    need to add some exceptions or special case rules for backwards
    compatibility with IEEE Verilog or SystemVerilog. We took a straw
    vote on classifying them like this:

        Object kinds: parameter, reg, the net types (wire,wand,wor,trireg, etc.)

        Datatypes: bit, logic, integer, real, time

    There were two abstentions based on a desire to see the rules for
    backwards compatibility; the rest think that this classification
    is fine.

    The messy keyword classification issue is "reg". There was general
    agreement that the others are relatively straightforward. The possiblity
    of introducing a new keyword, "var", was raised. This might allow "reg"
    to be equivalent to "logic" (as in SystemVerilog, and similar to the way
    that "wire" and "tri" are equivalent in IEEE Verilog). SystemVerilog has
    reserved "var" as a future keyword. We will discuss this "var" idea at
    our next meeting. Dave will try to find time to send a brief write-up or
    some examples.

    We will not meet the week of DAC (June 10).

    The next meeting is Thursday, May 27.

    This archive was generated by hypermail 2.1.4 : Fri May 14 2004 - 14:35:41 PDT and
    sponsored by Boyd Technology, Inc.