[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.
Received on Thu Nov 18 12:54:44 2004