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

                            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).
Received on Thu Oct 28 12:50:38 2004