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

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

  • Next message: Kathy McKinley: "[sv-bc] DataTypes: Datatypes meeting in 30 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.

    This archive was generated by hypermail 2.1.4 : Tue Nov 09 2004 - 08:17:55 PST and
    sponsored by Boyd Technology, Inc.