From: Kathy McKinley (firstname.lastname@example.org)
Date: Fri May 14 2004 - 14:52:27 PDT
- Kathy to ask for the following items on the next BTF agenda:
enhancement 287, and bit/logic datatypes
- Kathy to send some wording on bit and logic to the datatypes group
- Dave to send some words or examples on a possible "var" keyword
Minutes from last meeting approved.
We agreed to remove enhancement request 384 (mfactor) from the list
of issues that the datatypes group will consider. This issue is
fundamentally analog (voltage, power, and noise are involved
in the scaling algorithm). With that removed, the current list is
55, 61, 62, 357, 384, 385, 391
We can use email to add other items that we want to consider.
The contention around names for 2-state and 4-state datatypes is based
on concerns about keyword conflicts in existing Verilog designs.
Enhancement request 287 (`compatibility) discusses a directive
that could help a designer work around such problems. The datatypes
group strongly recommends that some mechanism like this be discussed
and approved at the BTF level. We will ask for 287 to be put on the BTF
agenda with high priority.
We unanimously endorse the keywords "bit" and "logic" for primitive
2-state and 4-state datatypes, respectively. These keywords denote
datatypes, not object kinds. These names should be keywords because
they are too fundamental to be redefined by the user. These names have
the following advantages:
- These names are natural to hardware designers
- These names are compatible with SystemVerilog
- These names are compatible in form and meaning with
the analagous SystemC types sc_bit and sc_logic
We spent some time discussing what it means to connect a 2-state net
to a 4-state net. This is a fundamental issue that needs to be resolved;
however, there is much to be considered. What do users want to see?
How does this affect port collapsing rules? How is performance and
optimization affected? We will continue to work on this issue.
We resumed discussion of meanings of existing Verilog keywords,
trying to classify them as "datatype" or "object kind". We may
need to add some exceptions or special case rules for backwards
compatibility with IEEE Verilog or SystemVerilog. We took a straw
vote on classifying them like this:
Object kinds: parameter, reg, the net types (wire,wand,wor,trireg, etc.)
Datatypes: bit, logic, integer, real, time
There were two abstentions based on a desire to see the rules for
backwards compatibility; the rest think that this classification
The messy keyword classification issue is "reg". There was general
agreement that the others are relatively straightforward. The possiblity
of introducing a new keyword, "var", was raised. This might allow "reg"
to be equivalent to "logic" (as in SystemVerilog, and similar to the way
that "wire" and "tri" are equivalent in IEEE Verilog). SystemVerilog has
reserved "var" as a future keyword. We will discuss this "var" idea at
our next meeting. Dave will try to find time to send a brief write-up or
We will not meet the week of DAC (June 10).
The next meeting is Thursday, May 27.
This archive was generated by hypermail 2.1.4
: Fri May 14 2004 - 14:31:52 PDT
sponsored by Boyd Technology, Inc.