Re: Extension Guidelines Group Deliverables

From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Tue Oct 28 2003 - 22:48:42 PST

  • Next message: Shalom Bresticker: "[Fwd: errata/497: add glossary section]"

    Thanks, Jay.

    I like this very much. I would be interested in participating in this.

    A few thoughts:

    - The Process Flow/Proposal Template should include an analysis of the
    influence on and by other extensions, and an analysis of the effect on other
    parts of the standard (e.g., timing checks, VPI) or required support by other
    parts of the standard.

    - Other task forces working on the standard (or their representatives)
    should be consulted for their comments before a proposal is finalized.
    This can be done as needed, but it is generally better to err on the side of
    caution.

    - There should also be guidelines for developing proposals for wording
    for the LRM, such as maintaining consistency with existing terminology,
    defining new terminology, and consistent use of terminology. Plentious
    use of examples.

    - We should consider a glossary section.

    On a personal note, I hope you will still be able to participate frequently.
    I highly respect your work and I've learned a lot from you. Your absence
    will be felt.

    Thanks and regards,
    Shalom

    Jay Lawrence wrote:

    > BTF members:
    >
    > Below you will find the writeup agreed to by the extension guidelines
    > group on what we believe our deliverables to be. This was unamimously
    > agreed to by the group members on 10/28/03. I'm now forwarding it to the
    > entire BTF so that at next Monday's meeting the charter can be discussed
    > and hopefully approved so that further work can proceed.
    >
    > On a more personal note, my role in Cadence is changing and I will not
    > be attending all the BTF meetings. As such, Kathy McKinley of Cadence
    > will be taking over my role in this committee and attending the BTF
    > meetings. She has broad experience in standardization, VHDL and Verilog.
    > I hope you all will welcome her to the group.
    >
    > Jay
    >
    > Extensions Guideline Group (EGG) - Deliverables
    >
    > The mission of the Extensions Guideline Group is to specify a set of
    > guidelines for appropriate uses of existing and new Verilog constructs
    > when extending the language. The purpose of these guidelines is to
    > ensure uniform and consistent usage of language elements in extension
    > proposals between multiple BTF subcommittees working simultaneously to
    > extend the language. The goal of the guidelines is to alleviate repeated
    > discussion of fundamental principles for each new language proposal, and
    > to define a process for submission, content and review of proposals by
    > the BTF. The end result of consistent application of these guidelines
    > will be a self-consistent Verilog 1364-200X language.
    >
    > The proposed deliverables of the EGG are:
    >
    > - Process Flow Specification
    >
    > This will document the process through which a potential language
    > enhancement request becomes a proposal from the BTF to the VSG. The
    > purpose of this specification is to ensure that there is a simple
    > well-documented process through which a technology donation or
    > enhancement request flows before becoming a part of the draft standard.
    > The scope of this specification is from donation/request through
    > presentation to the VSG. It is intended as a simple how-to guide and
    > does not set new guidelines, by-laws or rules.
    >
    > - Extension Guidelines Specification
    >
    > This document will analyze 1364-2001 and propose appropriate use of
    > existing language mechanisms when extending the language. This document
    > will consist of two parts, language principles and language constructs.
    > The language principles section will attempt to codify the "Spirit of
    > Verilog". Principles such as declaration before use, backwards
    > compatibility, built-in primitives, concise clarity, and implicit
    > declaration will be discussed. The purpose of the principles section is
    > to establish a set of guidelines that can informally be used to
    > determine if a proposed extension is "Verilog-like". The language
    > constructs section will analyze the components of the language such as
    > identifiers, comments, keywords, system tasks/functions, operators, etc.
    > and give guidelines on the role of that particular construct in the
    > language.
    >
    > The purpose of this specification is to aid in creating of the "Proposal
    > Evaluation Template" (below) and to document the consensus on
    > fundamental extension mechanisms. This discussion and documentation of
    > conclusions early in the 1364-200X process will avoid repeated debates
    > on these fundamental principles when individual enhancements are
    > considered.
    >
    > The scope of this document is originally the existing 1364-2001
    > specification. It is anticipated that this will be a living document.
    > During the standardization process the BTF may decide on additional
    > principles or may approve new language constructs that should be added
    > to the guidelines specification.
    >
    > - Proposal Evaluation Template
    >
    > This document will serve as a template to be completed by any
    > subcommittee or working group member actually making a proposal for
    > language extension. The purpose of this template is to provide a simple
    > way to document the extent to which a proposal conforms to the
    > guidelines provided in the Extension Guidelines Specification. The form
    > of this document will be a set of questions to be answered by the
    > champion of a given proposal. It may also prove valuable to committee
    > members evaluating a proposal.
    >
    > ===================================
    > Jay Lawrence
    > Senior Architect
    > Functional Verification
    > Cadence Design Systems, Inc.
    > (978) 262-6294
    > lawrence@cadence.com
    > =================================== 

    --
Shalom Bresticker                           Shalom.Bresticker@motorola.com
Design & Reuse Methodology                             Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd.                    Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL                       Cell: +972 50 441478

    This archive was generated by hypermail 2.1.4 : Tue Oct 28 2003 - 22:42:27 PST and
    sponsored by Boyd Technology, Inc.