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

From: Kathy McKinley (mckinley@cadence.com)
Date: Tue Nov 09 2004 - 16:15:38 PST

  • Next message: Mark Hartoog: "[sv-bc] DataTypes: vpi"

                                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.

    This archive was generated by hypermail 2.1.4 : Tue Nov 09 2004 - 16:03:56 PST and
    sponsored by Boyd Technology, Inc.