[sv-bc] DataTypes: 10/28/04 Meeting Minutes

From: Kathy McKinley (mckinley@cadence.com)
Date: Thu Oct 28 2004 - 12:50:31 PDT

  • Next message: Krishna Garlapati: "Re: [sv-bc] DataTypes: Plans for Dec. 1"

                                10/28/04 Meeting Minutes

    Attendees:

        Kurt Baty
        Jonathan Bradford
        Kevin Cameron
        Surrendra Dudani
        Krishna Garlapati
        Kathy McKinley
        Rishiyur Nikhil
        Dave Rich
        Steven Sharp
        Stu Sutherland

    Summary:

    We agreed to include both btf-dtype@boyd.com and sv-bc@eda.org in
    our email exchanges. Anyone with voting priveleges in sv-bc/ec/ac/cc
    or the BTF can vote in this datatypes subgroup.

    Because of the tight schedule, we decided to focus first on the most
    important and straightforward extensions. We can build on these later
    if we have time.

    The first priority is to extend net and port declarations to allow
    use of the new datatypes (e.g. packed structs) that are four-state based.
    We are starting with logic-based datatypes because the Verilog network
    semantics already support them. It may be more difficult to address two-state
    datatypes in the first revision because the network semantics and new
    datatype definitions are in different LRMs. Similarly, modifying the
    existing real definition (to be bit-based) is beyond the scope of
    this group. This should not preclude such extensions in the future.

    We voted unanimously to extend net and port declaration syntax
    in a manner that is analogous to the way that variable and parameter
    syntax have been extended. That is, following the net type keyword
    (wire, trireg, etc.), you can use a datatype from a typedef, or
    "inline" the definition of the datatype as a part of the net declaraion.
    No special net-specific syntax will be required. For example:

        wire logic foo;

    is now legal. The specification of the datatype does not affect the
    network behavior of the net. All other aspects of a net declaration
    (e.g. specifying a driver with strength) can still be used in a net
    declaration that includes a datatype.

    There was concern that a user might accidentally put a space in "trireg"
    and get the wrong behavior. That is, a user might type

        tri reg foo;

    when the user really wanted:

        trireg foo;

    Since most users will use "logic" rather than "reg" to declare a net,
    we discussed disallowing this keyword combination. There is precedent
    elsewhere in Verilog for disallowing typo-prone combinations. We voted
    on a lexical restriction that disallows "reg" to directly follow a
    net type keyword. The restriction passed with 3 abstentions and 0 no votes.
    Thus, the following is an error:

        wire reg foo;

    However, it is legal to use "reg" inside a struct and then use that struct
    to declare a net.
     
    There was some unhappiness expressed at using "reg" as a datatype name,
    but that issue has already been settled in SystemVerilog and it is beyond
    the scope of this group to reconsider it. So the "reg as datatype" discussion
    was terminated. Several times.

    You can specify a datatype in both ansi-style and separate-style port
    declarations. By default, an output port with an explicit datatype is
    a variable (this is true in SystemVerilog now). If you want the output
    port to be a net, you must include the net type keyword.

    Next week we will consider if we require the net type keyword in
    input and inout port declarations, and whether or not an input port
    should be a net rather than a variable. These ideas are discussed
    in the background mail that was sent earlier this week.

    We will try to use email this week to more formally define the syntax
    and semantics of the ideas that we approved today.

    We will meet next Thursday, Nov. 4, at 11:30am EDT (8:30am PDT).

    This archive was generated by hypermail 2.1.4 : Thu Oct 28 2004 - 12:39:41 PDT and
    sponsored by Boyd Technology, Inc.