[sv-cc] [Fwd: BOUNCE sv-cc@eda.org: Non-member submission from ["Maidment, Matthew R" <matthew.r.maidment@intel.com>]]

-------- Original Message --------
Subject: BOUNCE sv-cc@eda.org: Non-member submission from ["Maidment, Matthew R" <matthew.r.maidment@intel.com>]
Date: Fri, 22 Oct 2004 09:46:02 -0700 (PDT)
From: owner-sv-cc@eda.org
To: sv-cc-approval@eda.org

>From owner-sv-cc Fri Oct 22 09:45:51 2004
Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7])
        by server.eda.org (8.12.10/8.12.0.Beta7) with ESMTP id i9MGjpLS023546;
        Fri, 22 Oct 2004 09:45:51 -0700 (PDT)
Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6])
        by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MGjQSA009523;
        Fri, 22 Oct 2004 16:45:26 GMT
Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54])
        by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MGmwmt003975;
        Fri, 22 Oct 2004 16:49:28 GMT
Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60])
  by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102209454707576
  ; Fri, 22 Oct 2004 09:45:48 -0700
Received: from orsmsx403.amr.corp.intel.com ([192.168.65.209]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0);
         Fri, 22 Oct 2004 09:45:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
        charset="us-ascii"
Subject: FW: [sv-bc] SystemVerilog datatypes on nets
Date: Fri, 22 Oct 2004 09:45:44 -0700
Message-ID: <D30E01168D637641AA9D3667F3BB7416027F2B0A@orsmsx403.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sv-bc] SystemVerilog datatypes on nets
Thread-Index: AcS30vfphrmY0felQHONMQsb/HcehQAg3wsw
From: "Maidment, Matthew R" <matthew.r.maidment@intel.com>
To: <sv-ac@server.eda.org>, <sv-ec@server.eda.org>, <sv-cc@server.eda.org>
X-OriginalArrivalTime: 22 Oct 2004 16:45:45.0015 (UTC) FILETIME=[933CCC70:01C4B856]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a
        on server
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id i9MGjpLS023547

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of Kathy McKinley
>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?
>
>

-- 
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com