- Previous message: Kurt Baty: "draft of Process Flow Specification"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Hi BTF fellows,
From the very same EGG sub-committee, that brought you
Process Flow Specification and Extension Guidelines, here is the
the Checklist/Template to go along with them.
ennis
-----------------------------------------------------------------------
Extension Guidelines Checklist Template (EGCT)
-----------------------------------------------------------------------
The EG Checklist/Template, is a survey that is completed by the
proponent of a language enhancement proposal. The proponent might be an
individual, a company, a BTF subcommittee, or any another organization.
This Checklist would be used in the context of EGG Proposed Guidelines
and the Process Flow Document.
------------------------------------------------------------------------
Section [1]
-----------
ID:
[1.1] -- [number to identify the extension]
Name:
[1.2] -- [name of the extension proposal]
Synopsis:
[1.3] -- [explanation in one line]
PROBLEM:
[1.4] -- [what problem is the extension trying to solve]
Section [2]
-----------
EXTENSION:
[detailed explanation of the extension]
Checklist / Questions
[2.1] -could it be solved with current Verilog? if so what's the drawbacks?
[2.2] -what are the improvements that the extension provides
[2.3] -Does the extension introduce a new behavior?
Why is the new behavior important or desirable?
[2.4] - What requirements were imposed on the solution?
[2.5] - What alternatives or workarounds were considered?
[2.6] - What is the urgency of solving this problem?
[2.7] - Are there any copy rights Issues?
[2.8] - Is there an accompanying drawing, (if yes, is it in the
BTF frame maker format )
[2.9] - Has this extension been Implemented for the proposed use ?
Section [3]
-----------
Examples:
[usage examples]
Section [4]
-----------
BNF:
[BNF form of the extension]
Section [5]
-----------
KEYWORD:
[list of new keyword if any]
Checklist/Questions
[5.1] - Is this keyword already commonly used in user designs?
[5.2] - Does the extension introduce new syntax or lexical elements?
Section [6]
-----------
COMPATIBILITY:
[6.a] - Verilog 1364-1995
[6.b] - Verilog 1364-2001
[6.c] - Verilog-AMS
[6.d] - System Verilog
Checklist / Questions
[6.1] - Does the extension make any existing Verilog illegal?
[6.2] - Does the extension change the behavior of an existing design?
CONSISTENCY:
Checklist / Questions
[6.3] - Does the extension introduce something that is similar to an
existing aspect of the language? If so, is the form and use
consistent?
Section [7]
-----------
IMPACT: (Check list)
[7.a] -- Impact on LRM
[7.a.1] - What LRM sections are affected by this extension?
[7.a.2] - Does the extension introduce new terms or concepts?
[7.a.3] - Is the extension an addition to an existing class
of constructs?
[7.a.4] - How does the new construct interact with
existing constructs?
[7.a.5] - Are there Timing implications? How is the extension handled
with SDF?
[7.a.6] - Does the extension introduce a new kind of object
or datatype? if yes
[7.a.6.1] -- what operators are applicable and what are their
effects.
[7.a.6.2] -- Can it have x or z values or other special values?
[7.a.6.3] -- Can it have zero or negative values?
[7.a.6.4] -- Can the new data type be passed as a port ?
[7.a.8] - Does the extension add a new kind of design unit? How is the
design unit handled by a configuration?
[7.a.9] - Does the extension add a new kind of operator?
To what can it be applied? What is its behavior?
[7.a.9.1] -- How does the operator relate to x, z, 0,
negative, and real values?
[7.a.9.2] -- What is the bit-length of the result?
[7.a.9.3] -- How are operands extended?
[7.a.9.4] -- How does it handle signed operands?
[7.a.9.5] -- Is the result signed or unsigned?
[7.a.9.6] -- What is its precedence in order of evaluation?
[7.a.10] - Does the extension add a new kind of statement? Where
can it appear? What are its execution semantics?
[7.a.11] - Does the extension introduce a new structural element?
What is the form of a hierarchical name for the element?
[7.a.12] - Does the extension introduce a new kind of declaration?
To what name space do the new kind of names belong?
[7.a.13] - How is the new extension is scheduled for execution.
[7.b] Impact on VPI
7.b.1] - Are there VPI implications? Is the information model
updated? Are new routines introduced?
[7.c] Impact on VCD
[7.c.1] -VCD affected by this extension?
[7.c.2] -How is the new item handled with VCD?
[7.c.3] -How is the item referenced, and in what contexts
can references appear?
[7.d] Impact on other donations
[7.e] Impact on other Task Force(s)
[7.f] Possible impact on existing implementations
Section [8]
-----------
OTHER INFORMATION:
[8.1] Dependent Extension IDs:
[8.2] Folded Extension IDs:
[8.3] Related Extension IDs:
[8.4] Priority:
[8.5] Other:
Section [9]
-----------
COMMENTS / OPINIONS:
[Record various comments and opinions on the extension]
Section [10]
-----------
ISSUES and Action Items:
[List of issues to be discussed and solved]
==================================================================
- Next message: Kathy McKinley: "EGG Extension Guidelines"
- Previous message: Kurt Baty: "draft of Process Flow Specification"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Mon Dec 15 2003 - 00:49:24 PST
and
sponsored by Boyd Technology, Inc.