[sv-bc] DataTypes: Amended 11/04/04 meeting minutes

Here are the meeting minutes with the packed->unpacked correction:

                            11/04/04 Meeting Minutes

Attendees:

    Kevin Cameron
    Mark Hartoog
    Neil Korpusik
    Kathy McKinley
    Dave Rich
    Steven Sharp
    Stu Sutherland
    Doug Warmke

Summary:

The minutes from our last meeting were approved.

We focused first on a precise definition of what kinds of data types
can be used to declare nets. Our unanimous preference is to restrict
a net to a 4-state fixed length bit stream data type. Unfortunately,
we discovered some problems with the bit stream and fixed length
definitions that would need to be addressed, and they are beyond
the scope of our group to fix. Dave Rich will file an erratum
on the issue.

In the meantime, we will say that the following data types are allowed
for nets:

   1) A 4-state integral type

   2) An unpacked array or unpacked struct whose elements have a datatype
      that is allowed for a net

We will state in our proposal to the BC that we prefer the definition
to be based on the bit stream type if it can be fixed. We specifically
want to exclude tagged unions, classes, and strings.

We voted to allow the net type keyword to be optional in the declaration
of an inout port. If not specified, the net has the default net type.
The vote was 4 in favor, two against, and one abstention.

Steven Sharp has been working with Brad Pierce on extending the grammar
for datatypes on nets, based on our decisions. He will work with Brad
to incorporate this latest change for inout ports.

We briefly discussed making the default object kind of an input port
be a net. We identified a couple of cases where the user could tell
if the port were a variable or a net: you can connect an input variable
port to a ref port, or pass it to a constant ref argument; you could not
do this with a net. There is no keyword in the language to force
the port to be a variable, and though the keyword "var" had been
reserved, there is not enough time to make this kind of change.
This idea was tabled.

We then discussed documenting our proposal for the BC. We decided that
we should consistently use the term "data type", not "type" or "datatype".
We should provide glossary definitions for terms like "data type".
We will divide the proposal into two parts. The major part of the proposal
will be a set of critical changes that are necessary for defining this
extension in a way that can be correctly interpreted by LRM readers.
We will also provide a set of optional changes; they would make the LRM
more accurate, but the likelihood of misinterpretation without them
is not high.

We discussed Kathy's proposed changes for section 3.1. We will remove
the phrase "sorts of", change "type" to "data type", and insert the missing
word "add". The suggested changes in 3.6 and 3.7 fall into the optional
category. Erratum 197 is filed on section 3.6, so coordination would be
required if this change were made.

Steve's proposed changes to chapter 18 are fine, but there was
disagreement about whether or not they are optional. Some feel that
they are necessary because the LRM specifies variable, implying that
a net would not be allowed. Others feel that the reader could just assume
that it applied to nets too. Kathy will ask Matt Maidment for some
guidance on the matter and get back to the group.

Kathy will propose some changes to chapter 5 based on the decisions
made today.

We will meet next Tuesday, Nov. 9, at 12:00 EST (9:00am PST),
for an hour and a half. We will also have our regular meeting
next Thursday, which is the deadline for sending our proposal
to the BC.
Received on Tue Nov 9 08:29:43 2004