FW: [sv-ec] from: [sv-bc] SystemVerilog datatypes on nets

FYI.

-----Original Message-----
From: Kathy McKinley [mailto:mckinley@cadence.com]
Sent: Thursday, October 21, 2004 6:02 PM
To: btf@boyd.com; sv-bc@eda.org
Subject: [sv-bc] SystemVerilog datatypes on nets

Hello,

In October, the IEEE p1800 working group decided to move the 1364 BTF
datatypes subgroup to the p1800 BC. The BTF datatypes group had focused
on extending some of the new SystemVerilog datatypes (enums, packed
structs,
etc.) to nets. The charter of the datatypes group under the BC is to
propose a set of basic language extensions in this area.

Our goal is to get a simple set of extensions for nets in the first
revision of the IEEE SystemVerilog standard. This work will not be
allowed to slow down the overall SystemVerilog effort, so we will have
to be aggressive to get the extensions approved by the Dec. 1 deadline.
We will not be starting over or adding bells and whistles, we will be
focused on getting the basic capability into the language with the
minimal amount of disruption to the larger effort.

To expedite this process, the datatypes group will continue to operate
as a subgroup in the short term, and I will continue to chair it.
All existing datatypes group participants are encouraged to continue,
and
interested members of the p1800 EC/BC/CC/AC groups are welcome to join.
When we have a concrete proposal, it will be submitted to the BC for
consideration in that forum.

A second datatypes issue that was raised at the p1800 meeting related
to dynamic vs. static treatment of objects and classes. In the future,
we may want to allow static classes and dynamic structures (for linked
lists,
etc.). Exploring the current language definition to make sure that it
does not preclude such an extension in the future is another possible
task for this subgroup.

I have several background mails that I would like to send out when
we have the group reformed. In the meantime, I have appended an overview

of the 1364 datatypes effort and the orthogonality approach that the
1364 working group adopted for making this extension.

Due to the time constraint, we will probably try to conduct as much
business by e-mail as is feasible, but I would like to organize a weekly

meeting as well. We had been meeting on Thursdays at 11:30 am EDT,
but that time might not be the best for the extended group. If you are
interested in participating, can you please 1) let me know, and 2)
tell me when you are available (or not available) for meeting, including
your time zone?

Kathy McKinley

------------------------------------------------------------------------

--
SystemVerilog extended Verilog by adding powerful new datatypes and
operators that can be used to declare and manipulate parameters and 
variables. Extensions like packed structs provide a very convenient 
abstraction for manipulating an object that is really just a bit vector.
SystemVerilog did not extend these new datatypes to nets. However, 
with the addition of continuous assignments to variables, hardware 
designers can use the extended datatypes with variables to model 
many common network behaviors. Users would like to have these 
convenient abstractions for nets too, because other common network 
behaviors -- bidirectionality, multiple driver resolution, and delays 
-- cannot be modeled with variables.
The IEEE 1364 working group endorsed the concept of datatype 
orthogonality as the way to extend SystemVerilog datatypes to nets. 
Orthogonality is a fundamental principle of good language design. 
Datatype orthogonality means that the rules for how an object is updated
are independent from the set of values that the object can have. 
In most respects, extending SystemVerilog to allow new datatypes on 
nets is very straightforward. The LRM might need to talk about datatypes
a little differently, and the net and port declaration syntax needs 
extension, but the right thing to do is obvious and such changes 
would not impact existing SystemVerilog designs.
However, there appears to be a small number of areas where the "right"
answer is not obvious. Clarifications, restrictions, or perhaps even
minor changes might be required. A special datatypes subgroup of the 
behavioral task force was formed to identify and propose resolutions 
for such issues. 
The datatypes group adopted the classical programming language view 
of a datatype as a set of values and corresponding operations. 
The following issues were identified as needing exploration and 
resolution:
    - What are the semantics of nets and ports declared as two-state?
      How are multiple drivers handled? How are mixed 2-state and
4-state
      connections handled?
    - How do you use new datatypes to declare ports? When is a port 
      declaration a variable, and when is it a net?
    - What are the semantics and issues when ports using new datatypes 
      are connected to Verilog 2001 style ports?