[sv-bc] DataTypes: 11/18/04 Meeting Minutes

From: Kathy McKinley (mckinley@cadence.com)
Date: Thu Nov 18 2004 - 12:54:36 PST

  • Next message: Steven Sharp: "Re: [sv-bc] DataTypes: 11/18/04 Meeting Minutes"

                                11/18/04 Meeting Minutes

    Attendees:

        Jonathan Bradford
        Mark Hartoog
        Neil Korpusik
        Kathy McKinley
        Brad Pierce
        Dave Rich
        Steven Sharp
        Stuart Sutherland
        Doug Warmke

    Summary:

    Both sets of minutes from the 11/11/04 meetings were approved unanimously.

    We approved several changes to make the role of strength more clear
    in the proposal. We voted unanimously to make the following change
    in section 5. Replace the paragraph in our proposal that begins
    "The effect of this recursive definition is" with the following
    two paragraphs:

      The effect of this recursive definition is that a net is comprised
      entirely of four-state bits, and is treated accordingly. There is no change
      to the Verilog-2005 network semantics. In addition to a signal value, each
      bit of a net shall have additional strength information. When bits of signals
      combine, the strength and value of the resulting signal shall be determined
      as in Verilog-2005 section 7.10.

      There is no change in the treatment of the signed property across
      hierarchical boundaries.

    We voted unanimously to make the following change in section 3.
    After the paragraph in our proposal that begins "The Verilog-2001
    logic system is based on", add the following paragraph:

      The additional strength information associated with bits of a net
      is not considered part of the data type.

    We voted unanimously to modify the introductory picture with
    a bubble labeled "Net Strengths", and a line between the new
    bubble and the box labeled "net".

    We went through Surrendra's list of issues (in message 2361).
    We decided the following:

    1) We will not change the definition of data type. This passed with
       one negative vote. Stu would have preferred changing the term
       to "value type" because it has less baggage and would therefore
       be less confusing. Most felt that it is too late to make a change
       of that magnitude. The definition in the proposal is the classical
       computer science definition; the wording is very general, and
       the definition is in an informative section.

    2) We voted unanimously to change "construct" to "entity" in the
       following sentence in 3.1:

       "A data object is a named construct that has a data value
        associated with it, such as a parameter, a variable, or a net.".

    3) We voted unanimously to keep the net declaration syntax as it is
       in the proposal. The net declaration syntax was already complicated.
       You can write ugly examples with other kinds of declarations too.
       If you want a simpler declaration, you can use a typedef rather
       than inlining the type information.

    4) We voted unanimously to change the following line in the "Nets"
       section of 5:

       1. A four-state integral type

       to

       1. A four-state integral data type, including a packed array or
          packed struct

    5) There were mixed feelings about the lexical restriction. There was
       a valid reason for making this restriction, though everyone may
       not agree that the reason merits the restriction. Given that
       the vote to approve this restriction was made by a larger group
       in an earlier meeting, many of whom were not at this meeting,
       we felt that it would be inappropriate to overturn that decision
       when no new technical issue has been raised. We did not vote on it,
       and the earlier decision stands.

    6) We voted unanimously to leave the text in the proposal as it is.
       It is correct.

    7) We voted unanimously to replace the glossary definition of
       "data object" with the proposed text, with the extra "A data object"
       removed.

    8) This point is a question, and we were not sure exactly what
       it is asking. We need clarification in order to answer it.

    9) We agree that allowing two state would be better. We do not
       have time to complete the formal definition by the deadline.

    Stu will send Kathy the latest copy of the proposal, and she will
    update it with the changes that were approved today and send
    Revision 2 to the SV-BC later today. Those present can review
    the changes to make sure that they were made correctly. She
    will send the proposal to the SV-* chairs at noon EST on Friday.
    If notified of errors before then, she will correct them.

    We discussed Brad's proposed grammar changes for adding an
    optional "var" to the grammar for variable declarations.
    Some preferred a keyword order that is different from what
    he proposed, although nobody had strong feelings. Brad did
    it that way because it was easier, but he was open to changing
    the order. We informally decided that we prefer something like:

       const var automatic ...

    There was confusion about some of the grammar for classes.
    Brad had to leave before we finished, and we felt that we could
    not resolve the grammar issue without his expertise.

    If we can resolve the grammar issue for "var" through email
    in time, we will send a revision 3 containing the var change
    to the SV-* chairs on Friday. Kathy will propose some wording
    for the variable section in 5 to go with the change. Brad would
    need to propose a grammar with a different ordering in time for
    a little e-mail review and discussion. Based on how the discussion
    appears to go, Kathy will make a procedural suggestion for how
    to reach agreement through email. We do not want to put this change
    in on Friday if it looks like significant discussion is required.

    We will meet next at the SV-BC meeting on Tuesday. We can decide
    at the BC meeting when to meet next if we need to do so.

    This archive was generated by hypermail 2.1.4 : Thu Nov 18 2004 - 12:42:19 PST and
    sponsored by Boyd Technology, Inc.