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

                            11/09/04 Meeting Minutes

Attendees:

    Jonathan Bradford
    Mark Hartoog
    Neil Korpusik
    Kathy McKinley
    Dave Rich
    Steven Sharp
    Stu Sutherland

Summary:

The minutes from our last meeting were approved, with two amendments
related to the definition of what data types nets can have:

    1) The definition should say "unpacked arrays and unpacked structs"
       rather than "packed arrays and packed structs"

    2) We should be explicit that the definition is recursive

Some are not happy with this definition of the data types allowed on nets
because the recursion is too subtle. We will try to think of some better
wording by Thursday. Given that our preferred definition would be based
on bit stream data types, enhancing this definition may not be worth
much effort this week.

The term "data object" should be defined both in section 5.1 and
in the glossary. A data object is a construct that has a data value
associated with it, such as a parameter or a variable or a net.
All data declarations mentioned in 5.1 declare data objects.

We are not going to formally define an exhaustive list of which constructs
are data objects; there is no obvious place to put such a definition
(section 5.1 is informative), and it is late to be introducing this kind
of formal definition. A clear definition of the concept in informative
text will probably suffice for this revision of the standard.

The proposed new section on nets in Chapter 5 should say that if
a data type is not specified in the net declaration, the data type
of the net is logic.

The proposed new section on nets in Chapter 5 should state that there
is no intended change to the existing Verilog semantics related to net
resolution at the bit level, the role of strength, or the treatment of
signedness across hierarchical boundaries. Kathy will propose some wording
and we will revisit this section on Thursday.

We agreed to the proposed removal of the paragraph in 4.7 related
to arrays of wires. This removal creates a subtle difference in
compatibility rules, but this should not create a backwards compability
issue with existing user designs. The more general rule is probably better.

The proposed changes to chapter 18 rely on a set of type compatibility
rules that are not specific to variables. It is important for the
compatibility rules in chapter 5 to be general.

The last change proposed in chapter 18 does not attempt to change
the definition of compatibility. This text change defines the same kind
of compatibility that the original definition defined, so any issues
with this definition were not introduced by datatypes on nets.

Steven will send an updated set of proposed changes to chapter 18 that
reflect our decision to allow the net type in an inout port declaration
to be optional.

Steven will try to work with Brad Pierce to 1) formally define the
lexical restriction on the use of "reg" after a net type and 2) update
the inout port grammar to make the net type optional. If Brad does not
have time to help by Wednesday, Steven will do it by himself.

We will try to cover the rest of the LRM changes through email on
Wednesday. As proposals are sent through email, we should try to
raise issues through email that day so that we have time to think of
alternative wording, etc. before Thursday. We want to make our Thursday
meeting as productive as possible.

Our next meeting is Thursday, Nov. 11 at 8:30 am PST. This date is
the deadline for sending our proposal to the BC.
Received on Tue Nov 9 16:15:44 2004