Re: [sv-bc] SystemVerilog datatypes on nets

Bounced mail, see also http://boydtechinc.com/btf/archive/btf_2004/2364.html
.

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]
Sent: Friday, October 22, 2004 3:38 PM
To: sv-bc-approval@eda.org
Subject: BOUNCE sv-bc@eda.org: Non-member submission from ["Bradford
Jonathan" <Jonathan.Bradford@Micronas.com>]

>From owner-sv-bc Fri Oct 22 15:37:49 2004
Received: from raptor.micronas.com (raptor.micronas.com [192.166.137.1])
        by server.eda.org (8.12.10/8.12.0.Beta7) with SMTP id i9MMbkLS025037
        for <sv-bc@eda.org>; Fri, 22 Oct 2004 15:37:48 -0700 (PDT)
Received: from virtue.micronas.com by raptor.micronas.com
          via smtpd (for eda.ORG [171.64.101.101]) with SMTP; 22 Oct 2004
22:37:47 UT
Received: from cain.micronas.com [172.17.88.9]
        by virtue.micronas.com
        with XWall v3.31b ;
        Sat, 23 Oct 2004 00:37:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Subject: RE: [sv-bc] SystemVerilog datatypes on nets
Date: Sat, 23 Oct 2004 00:37:41 +0200
Message-ID:
<AEA1F6D31E97474BB72174D094A8369C01355B3F@EXCHANGE2.Micronas.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sv-bc] SystemVerilog datatypes on nets
thread-index: AcS30vDcZ34qIUkhSJeN45lldOrCkQAshjlg
From: "Bradford Jonathan" <Jonathan.Bradford@Micronas.com>
To: "Kathy McKinley" <mckinley@cadence.com>, <btf@boyd.com>,
        <sv-bc@server.eda.org>
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
i9MMbnLS025038

Hello Kathy

have you seen the proposal of sv-bc Errata 168, 'Complex Data Types of
Wires' ?
This proposal (168) is a basis to cover the issues you describe for your
initial goal,
an extension that does alter the current meaning of System Verilog.

Anyway I am interested. I am in the MEST zone (Paris, Berlin etc).

Regards

   Jonathan Bradford

____________________________________________________________________________
____

     /\ Jonathan Bradford
mailto:bradford@micronas.com
     \/
    /\/\ MICRONAS GmbH http://www.micronas.com
   /\/\/\
   \/\/\/ Hans-Bunte-Str.19 Tel: +49 (0)761 517 2884
    \/\/ D-79108 Freiburg Fax: +49 (0)761 517 2880
     \/ Germany

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Kathy
McKinley
Sent: Friday, October 22, 2004 3:02 AM
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?
Received on Fri Oct 22 15:45:33 2004