From: Kathy McKinley (mckinley@cadence.com)
Date: Fri Feb 27 2004 - 16:04:56 PST
Attendees:
Kurt Baty
Shalom Bresticker
Krishna Garlapati
Ronald Goodstein
Atsushi Kasuya
Francoise Martinolle
Kathy McKinley
Stuart Sutherland
Action Items:
- Kathy to send list of some datatype orthogonality conflicts
in the SystemVerilog definition
- Kathy to send keyword breakdown from Cadence proposal
Summary:
We will continue to meet every every other Thursday at 11:30 am EST
(8:30 am PST); however, from now on we will meet for two hours. Kathy
will send an email reminder when the meeting starts to get the attention
of those who have lost track of time.
We had homework to read the datatypes chapters in both SystemVerilog and
the Cadence donation as preparation for discussing fundamental principles
for our Verilog datatype extensions. We spent the entire meeting discussing
the principle of datatype orthogonality and how to apply it.
Datatype orthogonality means that the update semantics of an object
and the set of values that the object can have are independent of one
another. Data objects like variables and nets are different kinds of
objects because they have different simulation update semantics.
A variable gets new values from procedural assignments, while the value
of a net is determined from its drivers according to its resolution type.
Under the principle of datatype orthogonality, you can specify a value set
for an object (the set of real numbers, a set of structure values, etc.)
separately from the kind of the object (variable, net, etc.).
We unanimously decided to adopt datatype orthogonality as a fundamental
principle. The datatype of an object should not imply a particular
object kind, or vice versa. New datatypes should be available for all
kinds of objects, including nets, without introducing new keywords for
each combination of object kind and datatype (like "real" for a
real-valued variable and "wreal" for a real-valued net).
The Cadence donation follows the datatype orthogonality principle and
allows new datatypes on all objects. The SystemVerilog LRM does not
allow new datatypes on nets. In some areas, introducing datatype
orthogonality to SystemVerilog would simply be an extension; however,
there are some areas in which orthogonality and the SystemVerilog
definition conflict. We began the process of identifying such conflicts,
with no agreement on how to handle them when they are found.
We discussed the meaning of declarative keywords like "reg" and "logic".
In SystemVerilog, these keywords are synonymous. In the Cadence donation,
"reg" is an object kind and "logic" is a datatype. In the current IEEE
definition, "reg" implies certain simulation semantics; a prominent one
being that a reg can appear on the left-hand side of zero or more
procedural assignments.
Allowing a reg to appear in the member declaration of a struct and then
applying that struct to a net (which does not have "reg" update semantics)
muddies the update semantics associated with "reg". Many hardware designers
already find "reg" semantics confusing, so this may not be a big issue
for them. Verilog already "fixes things" for you in many cases, why not
this one? On the other hand, exceptions and ambiguity make it harder
for Verilog tool providers to understand and implement the same language.
We discussed the possibility of making a reg/logic exception for
SystemVerilog compatibility. Another possibility would be to prohibit
the use of reg in ways that violate the current reg update semantics.
A possible compromise would to allow reg to be used in contexts that
conflict with its update semantics, interpret the reg merely as a
datatype, and require a warning that the reg update semantics are
being ignored. The standard already requires warnings in a few cases;
this could be another one.
We reached no agreement at this meeting. We decided to try to categorize
all of the declarative keywords (object kind, datatype, or both) in our
next meeting.
SystemVerilog introduces a new construct, called an interface, that
can be passed through ports. Interfaces are similar to modules in
many ways; they represent collections of objects and hence do not
have datavalues in the traditional sense. It is too early to make
a conclusion about whether interfaces are datatypes or not.
The next meeting is March 4.
This archive was generated by hypermail 2.1.4
: Thu Mar 18 2004 - 05:27:13 PST
and
sponsored by Boyd Technology, Inc.