SystemVerilog datatypes on nets

From: Kathy McKinley (mckinley@cadence.com)
Date: Thu Oct 21 2004 - 18:02:12 PDT

  • Next message: Alec Stanculescu: "Re: 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?

    This archive was generated by hypermail 2.1.4 : Thu Oct 21 2004 - 17:52:14 PDT and
    sponsored by Boyd Technology, Inc.